информатика работни места
Днес ние ще говорим по-подробно за таблиците в Access.
Нека помним, че ние вече знаем за масите.
1. Идентификация (ключ)
Всички записи в таблиците са номерирани. За тази цел специално поле (по-добре е да се прави и първата покана и Id). Видът на тази област - брояч. Брояч всеки нов рекорд автоматично дава нов сериен номер. Този номер не може да се изтрие, не можете да промените (просто опитайте!).
Ако се премахнат от влизането на маса (например, Id = 12 - кученце Теди, когато той се разболява и не успя да вземе участие в изложението), а след това, ако той се възстановява, а вие да добавите отново Теди в таблицата, Id той ще има други, по 1 повече от последния запис в таблицата.
Това е да се гарантира, че идентификаторите в таблица в никакъв случай не съвпадат. В противен случай, те ще престанат да бъдат идентификатор!
В резултат на това, че е невъзможно да съвпада с броя идентификатори апартаменти, изложба nomerki кучета; Записи сортирани по Id не е задължително трябва да преминат по азбучен ред, по дата и час възходящ. С други думи, Id носят никакъв значим смисъл. Те само трябва да се създадат връзки между записите в таблиците.
2. Стандарти за именоването
Имена на таблици и полета в таблиците (и имената на заявки, формуляри, отчети и макроси), написани на английски език без интервали (посредством долна dog_age или всяка дума с главна буква DogAge). Преди името на масата се поставя префикс TB ... Така, записи стават четливи (например, tbDog.BirthDate), и няма проблеми с кодирането кирилицата.
Аз трябва да кажа, че достъпът не е позволено да пишат на кирилица имена и пространства. За имена с отделения не са "пръснати", той автоматично ги въвежда в квадратни скоби като този :. [киноложка изложба] [Важна информация 1]. Но изглежда непрофесионално и трудни имена визуалното възприятие.
3. Връзките между таблиците
Има два основни типа връзки между таблици: "едно към много" и "много към много". Не забравяйте примера на предишния урок?
собственици на кучета, породи кучета
Има само един собственик на всяко куче, но един собственик може да има няколко кучета
всеки съдия повдига оценката на няколко кучета, както и всяко куче получава оценката на множество съдии
Таблица (tbDog) създаде допълнително поле PersonId и пишат на собственика на всяко куче Id
създаване на допълнителни маси tbMark (прогноза) и в него са изброени по двойки: Каква оценка постави такъв съдия като куче
Илюстрация за "един към много" комуникация:
Илюстрация за "много-към-много" комуникация:
4. Режим на проектиране
В преглед на дизайна, ние искаме имената и типовете полета. са необходими Видовете полета, за да достъп до заявки за правилното прилагане на вградените функции (както и в Excel). Запомни, Пример 2 + 3 = 5, ако броят и # 147, # 2 148; + 147 # 3 # 148; = # 147; # 148; 23, ако тази линия. Друг пример: вградена функция за временни променливи месец (04.12.05) = 4 няма да бъде изпълнено, ако датата е записана линия.
Независимо има този тип като търсене Wizard. Всъщност, той не е вид. Магистър позволява най-простият вид връзка между двете таблици, "един към много". С други думи, тя позволява да се замени една маса стойност от друг. замествания съветника удобни, например, в заместващите стойности tbDog от масата скали. Тя ще изглежда така:
Така е в основната клетка на таблицата се вмъква малка падащите списъци, от които можете да изберете желаната стойност. Важно е да се разбере, че в този случай връзката между таблиците е създадена през ID. Просто майстор скрива техническата страна на нещата.
Също така в последния урок имаме малко засяга правата на проектиране схеми на бази данни. Днес ние ще се съсредоточи върху тях все повече и дават повече строга дефиниция.
При проектирането на тези схеми да се спазват три правила:
Правило 1: 1-во Normal Form
Според първата нормална форма във всяка клетка е най-малката единица на информация.
Не можете да записвате няколко стойности, разделени със запетаи. Ако логично възниква това решение, а след това ние се занимаваме с комуникация "много-към-много", както и в съответствие с правилата трябва да започне отделна таблица (както е в случая с оценки кучета).
Каква е причината на това изискване?
Отговорът е прост: на факта, че на масата след обработване на заявката!
Тя е много по-лесно да се уточни състоянието търсене tbMark.Exterior на> 5, отколкото да се търсят в дълга линия # 147; 5, 4, 6 "влизане в нея желания подниза и след това се изравнят грешката.
Същото важи и за дългите съставни стойности, например Lang. Ако фамилия, име и фамилното име се записват в отделни клетки, ние лесно с помощта на заявки могат да се показват в зависимост от задачата:
- фамилия, име и презиме,
- Само името,
- Фамилия инициали,
- презиме и т.н.
С искания не може да бъде трудно да се направи избор на тези читатели, които изтича тази седмица, ако датата на връщане е написано в една клетка:
Също така няма да е трудно да се избере от база данни на всички жители на Москва:
Изключенията са тези елементи, които очевидно не искат да се търси. Така че в последния пример, не би било разумно да се направи номер на апартамент в отделно поле, тъй като е малко вероятно, че някой ще трябва да се покаже цялата налична в базата данни на жителите на 50-та апартамента.
В допълнение към 1NF трябва да кажа още един важен момент: както вече знаете, достъп ви позволява да създавате заявки и изчисления: дата на раждане, за да се определи възрастта на името и бащиното направя инициалите и т.н. Ето защо, само на първоначалните данни (дата, на разходите за единица на стоки) трябва да бъдат посочени в клетките на таблицата и не пишат за тези, които могат да се изчислява въз основа на функциите.
Правило 2: локално хранилище
По силата на принципа на съхраняване на данни на местно ниво, ако стойността във всяка област се повтарят периодично, те трябва да стоят в отделна таблица, както и в областта, за да ги поставите връзка.
Не забравяйте примера на скалите? В таблицата с кучетата редовно повтаря имена скали. Да не пиша двадесет пъти "кокер", ние се създаде отделна маса с скалите и таблицата показва само Id порода кучета. (Между другото, какви отношения ще има?)
По този начин,
а) ще се спаси от ненужната работа (не е необходимо да попълните много пъти едно и също нещо);
б) ако искате да направите промени, което е достатъчно, за да редактирате едно поле, а не на няколко десетки или дори стотици записи.
Това правило не е задължително да се съобразят с само един случай: ако повторението, но те не са редовни. Например, не би било разумно да се създаде отделна таблица с фамилия, имена и бащиното, въпреки че това се случва, че те се повтарят.
Правило 3: АСОЦИАЦИЯ НА МАСИ
Ние говорихме много за това, което трябва да се разделят на масата в няколко (за да се съобразят с първите две принципи: 1NF и съхранение на местно ниво). Сега е време да се говори за това, кога да се комбинират няколко маси в едно.
Ако се преведе първите две принципите на обикновен език, можете да (с някои загрубяването) казва: едно лице - една таблица. Таблица за кучета, таблицата за собствениците, таблицата за оценка, маса за скалите и т.н.
Въпреки това, има случаи, в които трябва да се направят няколко лица в една таблица! Какви са тези случаи? Това, когато няколко лица са почти идентични схема на данни (съвкупност от полета в таблицата).
Така например, в нашето шоу кучета са въвлечени не само на собствениците на кучета, но и членовете на консултативния съвет (съдията). Можете да създадете отделна таблица за tbExpert съдии, но това е по-удобно да пиша и тях, и собственици в отделна таблица tbPerson (въведени да се прави разлика само едно допълнително поле IsExpert).
По този начин, ние не само да създаде допълнителни таблици, но също така се спаси от налага да пиша някои допълнителни искания (например, искане, което на фамилията, името и бащиното фамилно име прави с инициалите). Такова искане ще трябва да се дублира за всяка една от масите.
Така че, третият принцип е формулиран по следния начин:
Ако няколко лица имат почти идентични схеми на данни, те трябва да бъдат обединени в една таблица.
Не се страхувайте, че на масата ще бъде върху него прекалено дълго. Данни на Guide-Bulgaria.com работят добре с много дълги маси (аз работих с базата данни в Access, което е малко повече от 1 милион записи, а достъп се справя с него!) Студенти от различни групи, курсове и отдели, продукти от различни видове, книги от различни жанрове - като всички те могат и трябва да бъдат обединени в една таблица (tbStudent, tbGoods, tbBook съответно) със специален поле (poyami) -labels: изпълнител, жанр и т.н.
Списък отново се изработи принципи:
1. 1NF: във всяка клетка е най-малката единица на информация.
2. Местна съхранение: ако стойностите в дадена област, периодично повтарящи се, те трябва да стоят в отделна таблица, а в пощенската връзка.
3. Комбинирането на таблици, ако няколко лица са почти идентични схема данни, те трябва да бъдат обединени в една таблица.
И не забравяйте за правилата, за които говорихме по-рано:
1. Във всяка маса първото поле - вида на ID брояч.
2. Правила за именуване: на английски език без интервали (всяка дума с главна буква), + префикс TB ...
3. Две видове взаимоотношения: един-към-много (област създадете линк), много-към-много (създаване на допълнителна маса).
Сега стигаме до упражняване на професията.
Задача 1 Изберете всеки три от петте предложения следните задачи и да направи по списъците с данни на схема на база данни. Схеми изготвят на хартиен носител (не е задължително да ги направи в Access) и вземете със себе си по своя собствена.
1. Холивуд
Iconic холивудски филми.
- имаме две лица: хората tbPerson и филми tbFilm;
- tbPerson изброени в Таблица актьори и режисьори;
- всеки филм може да бъде само един директор, а един директор може да стреля няколко филма;
- всеки филм записвате няколко актьори и един актьор може да действа в няколко филма.
2. Cool Magazine
Учителка по математика в училище, за да даде на студентите марка за работата им в класната стая. Всеки урок се фокусира върху нова тема.
3. мобилен оператор
Мобилният оператор поддържа база данни с информация за своите абонати.
4. Клуб по конен спорт
Любителите на конната езда се записват на класовете в училище, езда. В зависимост от нивото на тяхната подготовка, те могат да участват в по някои коне. Коне лично, всеки има законния собственик.
5. автоматично Network
Чуждестранните автомобили се продават в мрежата дилъри.
Задача 2 Проучване на видовете полета в Access и инсталирате подходяща: