Планирование и проектирование вашей базы данных в Access
Скачать 235.02 Kb.
|
| Министерство Образования Республики Беларусь Белорусский государственный университет экономический факультет Константин Иванович Кравченко Планирование и проектирование вашей базы данных в Access Студент I курса отделения менеджмент Минск 2007 Содержание Введение…………………………………………………………………………..……2 Продумайте ваши данные перед тем, как создавать вашу базу данных....................4 Зачем нужны реляционные таблицы?...................................,.......................................4 Разработка базы данных и нормализация.....................................................................6 Избежание повторения данных..............................................................................7 Основы нормализации............................................................................................8 Первая нормальная форма - устранение повторяющихся групп........................9 Вторая нормальная форма и устранение избыточности....................................11 Третья нормальная форма - устранение неключевых столбцов, не зависящих от ключа..........................................................................................13 Нормализация в Access.................................................................................................14 Литература………………………………………………………………………….. 19 -2- Планирование и проектирование вашей базы данных Введение Представляете ли вы себе строительство дома без чертежа или сборку автомобиля без схемы? Здравый смысл подсказывает нам, что такое невозможно. Более того, это только говорит нам, что необходимо потратить время на проектирование вашей базы данных перед тем, как создавать ее. Это сэкономит время на продолжительном этапе разработок, потому что вам удастся избежать неприятностей, связанных с исправлением ошибок, свойственных плохо разработанным приложениям. Этот реферат посвящен тому, как применять принципы базы данных в ваших разработках. В частности, вы узнаете: • о получении данных из внешних источников; • почему важны реляционные таблицы; • о дизайне базы данных и нормализации; • почему следует избегать повторяющихся данных; • об основах нормализации; • о первой, второй и третьей нормальной форме; • как сделать так, чтобы Access автоматически выполнял нормировку для вас. -3- Продумайте ваши данные перед тем, как создавать вашу базу данных Я расскажу вам о том, как получать данные из внешних источников, что относится к более широкому кругу, чем просто покупатели, клиенты, глобальная сеть, электронная почта, внешняя универсальная ЭВМ или источники в Интернете. Внешние источники могут быть и внутри вашей компании или даже внутри вашего отделения. Термин «внешний» обозначает все, что находится вне Microsoft Access. Что вы делаете с данными, которые вы лично не проверили на согласованность, точность и полноту? Даже если вы сгенерировали данные сами (скажем, с помощью такой программы, как Microsoft Excel), как вы узнаете о том, что они согласованы с правилами «нормализации баз данных» (обсуждаемых в разделе «Избежание повторения данных») для создания баз данных, во время импортирования их в Access? А конкретней, всегда ли ZIP-коды полны и точны? Всегда ли запятая отделяет город от штата? Нужно ли разбирать (отделять) данные по отдельным полям? Были ли данные проверены? Например, все ли номера социального обеспечения имеют одинаковое число знаков? Microsoft Access обеспечивает проверку данных, введенных в базу данных Access, а что же насчет данных, введенных в другие пакеты программного обеспечения? Спокойствие: у Microsoft Access есть множество инструментов для того, чтобы помочь вам проверить данные даже «в соответствии с обстоятельствами». В моем реферате описаны такие методы для подготовки данных, которые стали бы частью совместимого и хорошо спланированного приложения. Кроме инструментов для анализа и очистки данных при их подготовке к использованию в приложении, существуют также принципы разработки, которые должны быть четко уяснены и применены для того, чтобы убедиться в связности и полноте данных. Так что перед тем, как заняться «внешним», давайте-ка заглянем внутрь. Зачем нужны реляционные таблицы? Давайте поговорим о разработке базы данных. Почему же так важно иметь реляционные таблицы в базе данных? Почему бы не использовать их подобно тому, как мы используем обычную табличную программу1- в двумерных таблицах? Разве и так нельзя вести расчеты и добавлять записи? Все потому, что «настоящие» ситуации устроены совсем не так. Сколько покупателей лишь закажут один товар? Сколько работников будут лишь зачислены на один проект? Сколько студентов будут посещать лишь один курс? Мы живем в трехмерном мире типа «один ко многим». И хотя двумерность сойдет для обычной табличной программы, базы данных все же имеют более жесткие конструкции; эта дополнительная размерность может быть огромным преимуществом. База данных, построенная на двумерном файле, является двумерной моделью. Что это означает? Если вы представите себе таблицу как электронную таб- _____________________ 1 В качестве обычной табличной программы можно рассмотреть программу Excel. В ней можно вести записи и расчеты, но она создана для плоских или двумерных таблиц. -4- лицу с рядами в виде записей и полями в виде колонок, получится, что вы смотрите как бы на одну сторону этой таблицы, так сказать. Реляционная база данных добавляет третье измерение. Теперь вы можете представить себе ее длину, ширину и глубину. Ряды - это ширина, колонки - это длина, а зависимость - это глубина (см. рис. 1.1).  Рис. 1.1. Эта трехмерная электронная таблица показывает область как ширину, колонку с годами как длину и реляционную последовательность данных о годах как глубину На первый взгляд все это выглядит как двумерная модель. Фактически это и есть двумерная модель, если вы представите ее в виде строк и столбцов. Но финансовые данные в столбцах трехмерны, если правильно это себе представить, как показано на рис. 1.2.    Рис. 1.2. Осмыслить таблицу с данными лучше всего, посмотрев на нее с трехмерной точки зрения Заголовки столбцов имеют одно общее свойство: все они обозначают годы. В базе данных вам хотелось бы хранить общую информацию в категориях, называемых полями. Более подробно это будет обсуждаться позже, но дизайн на рис. 1.1 и 1.2 не является хорошей моделью базы данных. Например, если бы вы хотели подвести итог по финансам в юго-западной области, вы бы легко могли подставить формулу в клетку справа в обычной табличной программе. Но в базе данных вам требуется вычисляемое поле для всех четырех столбцов. В любом случае подстановка этих итогов в поле обычно не является лучшим способом разработки базы данных. А если вам требуется подытожить все поля с финансовыми данными, то это, хотя и возможно, является наиболее быстрым или эффективным способом задания запроса. Пример на рис. 1.3 -5- - более правильная модель базы данных, хотя все еще с недостатками. Заметьте, что годы размещены в поле с названием Год, а финансовые данные помечены как Продажи.  Рис. 1.3. Лучшая, но все же с недостатками трехмерная таблица, показывающая Год и Продажи как отдельные поля Теперь по крайней мере пользователь знает, с какой информацией он имеет дело. Пользователь может сделать запрос по группе и легко найти итог для каждого года или области или комбинации того и другого. Единственная проблема состоит в том, что в этом примере показана излишняя (повторяющаяся) информация. Наоборот, в каждом поле должны быть различные значения. Единственным способом установления уникального поля в предыдущем случае является объединение первых двух полей в одно. Это более совершенный способ. Разработка базы данных и нормализация К этому моменту вы уже должны были бы знать, что база данных - это совокупность информации, относящейся к определенной теме. Но как организовать эту информацию с максимальной эффективностью? Правильная разработка базы данных - вот ключ для решения этой задачи. Таблица - сердце базы данных. Это то место, на которое прямым или косвенным образом направлена большая часть вашей работы над базой данных. Но то, что у вас имеется несколько таблиц, связанных друг с другом в вашей базе данных, еще не означает, что они готовы для функционирования базы данных. То, что нужно рассмотреть при разработке базы данных, включает: • назначение базы данных; • необходимые таблицы и поля; • необходимые связи между таблицами; • указание, как избежать излишних данных; • указание, как убедиться в согласованности данных. Когда вы обдумаете эти пункты, вы быстро придете к мысли о том, как полезна нормализация данных, которая есть процесс упрощения разработки базы -6- данных, целью которого является получение максимальной эффективности и согласованности. Одни говорят, что нормализация - это процесс нахождения и удаления излишних данных и аномалий в базе данных, связанных с ними. Другие утверждают, что нормализация есть процесс разбиения таблиц на более мелкие компоненты с целью оптимизации. Некая комбинация этих определений почти что верна. Чтобы убедиться в правильности разработки базы данных и структуры таблицы, необходимо во что бы то ни стало избежать двух изъянов разработки: избыточности и несогласованности. Если у вас есть таблица с излишним числом полей или с большим количеством излишних (повторяющихся) данных - это сигнал, что требуется нормализация. Разбивая ваши таблицы на более мелкие таблички и обеспечивая связь между схожими табличками, вы выполняете несколько задач, которые включают: • избежание повторяющихся данных, как внутри самой таблицы, так и внутри связанных (схожих) табличек; • максимизацию скорости и эффективности вашей базы данных; • обеспечение того, что одинаковые данные никогда не будут помещены более чем в одно поле; • экономию дискового пространства путем избежания излишних данных; • обеспечение согласованности и единообразия данных, будь то входные или выходные данные; • создание дизайна, который гораздо более удобен, чем таковой с ненормализованными данными, для поддержания и управления; • создание механизма для поисков по условию в запросах, формах или отчетах. Теперь давайте рассмотрим эти вопросы на примере. Избежание повторения данных Если вы храните данные в более чем одном мете (будь то одна и та же таблица или две и более), вы создаете избыточность данных. Почему же избыточность так нежелательна при разработке базы данных? Скажем, у вас имеется поставщик, который едет из Хьюстона в Даллас, и 50 строк с данными, содержащими их адреса; то тогда вам нужно менять все 50 строк. Это то, что называется аномалией при обновлении. Чтобы поправить такое положение, если вы удаляете часть, относящуюся к этому поставщику, в нереляционной модели, вы также удаляете поставщика. К счастью, существует лучший подход для достижения оптимального дизайна базы данных. Здесь мы введем термин внутренняя избыточность, который означает избыточность внутри таблицы, тогда как термин внешняя избыточность будет означать одинаковую информацию (неключевые поля), которая содержится более чем в одной таблице. Внешняя избыточность свойственна электронным таблицам. Это потому, что не допускается хранение информации в нескольких таблицах, бланках или рабочих журналах. Таблица на рис. 1.4 показывает примеры избыточности. Сначала представьте себе таблицу на рис. 1.4 без первого столбца. И что теперь вы с ней будете делать? Когда возраст Джейн изменится, вам потребуется -7- поменять целых три записи, вместо того чтобы поменять лишь одну. Без первого столбца вы ни с чем не сможете связать эту информацию, потому что у вас нет «крючка», или точки, к которой вы прикрепляете информацию; поэтому информация становится фактически бессмысленной. Первый столбец - единственный уникальный столбец в таблице. Но даже с первым столбцом дизайн функционально небезупречен.  Рис. 1.4. В этой таблице с избыточной информацией есть только одно уникальное поле - Project ID Столбец Project ID обеспечивает «крючок». Это ключевое (уникальное) поле может быть связано с другой таблицей, называющейся Projects, которая может содержать любую информацию о каждом проекте. Все, что вам требуется, чтобы устранить избыточность, - это присвоить Джейн уникальный Employee ID (номер служащего) (ибо Джейн не очень-то уникальное имя) и поместить ее в таблицу Employee (Служащие). Вы даже можете использовать номер ее социального обеспечения, так как вам известно, что он-то уж точно уникален. Затем вы можете связать ее с таблицей Clients (Клиенты), таблицей Prospects (Потенциальные клиенты) или другими таблицами; список можно продолжать и продолжать. Посмотрите на результаты устранения избыточности на рис. 1.5.  Рис. 1.5. В этой таблице Джейн имеет свой уникальный Employee ID (ID служащего) и помещена в таблицу со своими сослуживцами Основы нормализации В 1969 году человек по имени Е. F. Codd изобрел модель реляционной базы данных. Для достижения оптимальной структуры он создал нормальные формы - последовательность правил, которые вы применяете к вашей базе данных с каждым уровнем нормальной формы, улучшая общий дизайн. Если бы вы хотели собрать базу данных служащих для отслеживания их клиентов, вам следовало бы устроить поля так, как показано на рис. 1.6. На рис. 1.6 - ненормализованная таблица. Первая проблема, которая кроется в полях, очевидна. А что если вам требуется отследить более чем двух клиентов на каждого служащего? А точнее, что если Стэнли, у которого уже есть два клиента, -8- приобретет еще одного? Добавление еще одного поля - плохой способ, потому что это делает таблицу более сложной и неэффективной.  Рис. 1.6. Эта ненормализованная таблица имеет внутреннюю избыточность и повторяющиеся поля В первой нормальной форме не должно быть повторяющихся групп (столбцов), поэтому нам придется считаться с тем фактом, что у нас есть два повторяющихся поля. Чтобы изменить ситуацию, у вас не должно быть нескольких полей в одной и той же категории. Это-то и есть поле для большинства случаев -категория. Имея два поля с ID клиентов и два поля с именами клиентов, затруднительно выбирать, сортировать и отслеживать информацию правильно. Как правило, нет никакой нужды в двух или более полях с одинаковой информацией. Проблемы можно подытожить следующим образом: • нулевые значения, если у служащего есть только один клиент; • нельзя отследить более двух клиентов; • повторяющиеся группы (проблематично отследить); одинаковый тип данных в более чем одном поле. Единственное, что можно сказать хорошего о таблице на рис. 1.6, - это то, что информация о служащих в ней уникальна. Первая нормальная форма - устранение повторяющихся групп Как решить проблему повторяющихся групп или другие проблемы, связанные с ненормализованными таблицами, и в то же время гарантировать, что вы сможете отслеживать клиентов таким образом, каким вы намереваетесь это делать? Посмотрите на рис. 1.7, на котором показана та же информация, но только в другом представлении, и с одним лишь исключением.  Рис. 1.7. Хотя первая нормальная форма решает кое-какие проблемы, все же она несовершенна -9- На рис. 1.7 добавлен код штата для каждого клиента. С таким добавлением таблица может содержать любое количество клиентов на каждого служащего. Но решение одной проблемы породило другую, которая таится в записях. Таблица теперь содержит внутреннюю избыточность информации о служащих. Вы уже достигли первой нормальной формы, что является улучшенным дизайном по сравнению с тем, с которого вы начали, но до оптимального дизайна еще далеко. Вам все же нужно установить первичный ключ*. Хотя информация о служащих в ненормализованной таблице и уникальна, все же новый дизайн содержит излишнюю информацию о служащих. С другой стороны, заметьте, что одно поле отслеживает ту же информацию, которую раньше отслеживали два поля. В этом заключается преимущество этой формы перед предыдущей, но все же она не идеальна. Первичный ключ Первичный ключ - это поле (или ряд полей), которое однозначно идентифицирует каждую запись в таблице. Access не допускает повторных значений в поле первичного ключа. Более того, вам обязательно нужно фиксировать значение каждой записи поля первичного ключа для того, чтобы быть уверенным в том, что у вас нет записей без значений. Это и есть то, чего требует реляционная модель. И в этом есть смысл. Разумеется, что вы не хотите дублировать номера заказчиков, если вы желаете идентифицировать заказчика. Access не требует создания первичного ключа в каждой таблице, но это настойчиво рекомендуется, так как если вы сделаете это, то вам же и лучше. Ситуации могут различаться, но это основополагающий принцип. Из-за того, что поле Employee ID неуникально, вам нужно создать составное (два поля действуют как одно) поле, которое выполняет функцию ключа для создания уникальности. В этом случае вы могли бы соединить поля Employee ID и Client ID. Заметьте, что если вы скомбинировали эти два поля в одно, то это создаст уникальное поле. Другими словами, два поля, соединенные вместе, не будут повторять друг друга. А чего бы это им повторять друг друга? Зачем нужно дважды отслеживать служащего с таким же клиентом? Даже если первая нормальная форма позволяет установить первичный ключ, тот факт, что он является составным ключом, - индикатор того, что вторая нормальная форма еще не достигнута. Если вы разобьете эту таблицу на две, вы все равно не решите проблему избыточности, т. е., пока вы не дойдете до следующего уровня. У вас могут возникнуть ситуации, когда избыточности практически невозможно избежать. Предположите, что в предыдущем примере вместо того, что у служащего есть много клиентов, у одного клиента, использующего множество служащих, также есть другие клиенты. Такой вариант, который в целом возможен, порождает избыточность. Но помните, что мы здесь всего лишь определяем понятие «норма». Вероятно, это потому, что они называются нормальными формами. Существуют и такие ситуации, когда возможна денормализация. Для этих редких случаев, существуют основные правила, которым нужно следовать, чтобы ____________ *Здесь имеется в виду ключевое поле. Обычно определение «первичный» опускается. -10- правильно «нарушать правила». В эти правила включают описание каждого шага процесса денормализации и вносят необходимые поправки в применение, дабы избежать отклонений и несовместимости. Несовместимые данные Избыточность создает отклонения, а отклонения создают несовместимость. Предположим, что у вас есть порядковые номера, для которых заказчиков нет. Это случается, когда таблица с заказчиками не связана*, а число заказчиков изменилось или информация о заказчике удалена из таблицы заказов. Эти заказы, становятся как бы «потерянными данными», которые «живут» где-то сами по себе, занимая место, и не являются связанными. Это потому что заказ зависим от заказчика. Другой тип несовместимости, упомянутый выше, получается, если вы вводите данные в нескольких местах. Имя может быть написано правильно в одном месте, а в другом нет. Здесь нормализация минимизирует ошибку человека. Но с помощью первой нормальной формы вы все еще не устранили избыточность или несовместимость. Табл. 1.1 показывает, что может быть сделано с помощью первой нормальной формы, а что нет. Таблица 1.1. Возможности первой нормальной формы
Вторая нормальная форма и устранение избыточности Для того чтобы таблица имела вторую нормальную форму, для начала ее надо привести к первой нормальной форме. Еще одно условие состоит в том, что каждый неключевой столбец должен быть полностью зависим от всего первичного ключа в целом. Это означает, что если у вас есть составной первичный ключ, то другие неключевые поля должны полностью, а не частично зависеть от первичного. Рис. 1.8 иллюстрирует полную зависимость во второй нормальной форме. ______________ *Здесь автор имеет в виду, что две таблицы - таблица «заказчики» и таблица «заказы», должны быть связаны друг с другом. -11-   Рис. 1.8. Чтобы получить вторую нормальную форму, никаких частичных зависимостей быть не должно Частично зависимые элементы Частично зависимые элементы лишь зависят от части первичного ключа, а не от всего первичного ключа в целом. Поэтому, если у вас есть составной ключ, есть хорошая вероятность того, что у вас имеется частичная зависимость и первая нормальная форма. Заметьте, что на рис. 1.8 поле Employee Name полностью зависит от поля Employee ID, а не отчасти зависит от него и еще какого-то поля, создавая таким образом композицию. Так, вы можете заключить, что рис. 1.8, который является примером второй нормальной формы, не содержит каких-либо частичных зависимостей. Мы также можем утверждать, что зависимость во второй нормальной форме будет автоматическая, если она содержит первичный ключ, состоящий из одного показателя (а не составной!). Обратите внимание на уменьшение повторения. Записи Employee Ids (ID служащих) 34, 10 и 17 сохраняются один раз, а не два, как это было в предыдущей форме, показанной на рис. 1.7. Зависимость «один ко многим» Таблица Employees (таблица служащих) является первичной таблицей и первой в зависимости «один ко многим». Скажем, у вас есть один служащий со множеством клиентов. Так как поле Employee ID есть в обоих таблицах, то оно называется общим полем. Тем не менее, поле Employee ID в таблице Clients (связанной) называется внешним ключом. Также примите во внимание то, что унифицированность не так уж сильно важна в идентичности имен полей; гораздо более -12- важно то, чтобы данные в этих полях совпадали. Связывание полей Employee ID в двух приведенных в качестве примера таблицах и есть то, что устанавливает зависимость «один ко многим». Вы можете пронаблюдать зависимости между таблицами в окне Relationships. Вам может показаться, что вторая нормальная форма есть наивысшая форма, ибо она имеет много преимуществ, но это вовсе не так. На самом деле «кодд» (Codd) определил третью нормальную и несколько других форм более высокого уровня. В этой главе рассказано о третьей нормальной форме, ибо другие формы не привносят ничего особо положительного по сравнению с третьей. Для получения третьей нормальной формы вам все еще требуется исправить кое-какие недостатки дизайна. Третья нормальная форма - устранение неключевых столбцов, не зависящих от ключа Что же насчет данных о штате, которые вы добавили? Тут есть только одна повторяющаяся запись. А правильно ли это? В третьей нормальной форме вы ищите неключевые столбцы, которые независимы от первичного ключа таблицы. И не путайте связь с зависимостью. Ключ State Code (Код штата) связан с данными о клиенте, но не зависит от них функционально. Это называется переходной зависимостью. Не удивительно то, что у вас имеются повторяющиеся значения, так как два или более клиента могут быть из одного и того же штата. Поле State Code может действовать само по себе в справочной таблице и без данных о клиенте. Можно рассмотреть этот вопрос и с другой стороны: поле State (Поле штата) зависимо от неключевого поля (State Code). Если компания переезжает и код штата меняется; то штат меняется тоже. Это не соответствует третьей нормальной форме. Во второй нормальной форме вы устранили частичные зависимости; в третьей же нормальной форме вы устранили переходные зависимости. Это существенное различие. Информация о коде штата должна быть перемещена в новую таблицу и использоваться как справочная таблица. В третьей нормальной форме вы устранили избыточность, с двумя лишь исключениями. Первое - это поле Employee ID. Сохранение зависимости «один ко многим» возможно. Второе - это поле State Code в таблице Client ID. Это также возможно, так как его можно использовать для справки, если потребуется. Сторона «многие» зависимости «один ко многим», как и сторона «один» зависимости «многие к одному» являются возможными значениями полей, которые можно повторять, так как мы говорим лишь об одном поле. Основная задача состоит в том, чтобы сохранить место путем использования одного поля таким образом, чтобы связать столько информации в связанных таблицах, сколько вам потребуется. Заметьте, что на рис. 1.9 справочное поле State Code в таблице Clients сделано как связное поле. -13-    Рис. 1.9. Этот пример третьей нормальной формы иллюстрирует устранение переходных зависимостей Нормализация в Access Теперь вы готовы к тому, чтобы приступить к изучению практической части. Это будет легко и занимательно. Таблицу на рис. 1.10 проанализирует мастер анализа таблиц, который работает, следуя принципам нормализации  Рис. 1.10. Это таблица CustOrder, которая будет проверена анализатором таблиц Чтобы Access автоматически нормализовал вашу таблицу, выполните следующие операции: 1. Выберите Сервис/Анализ/Таблица из меню Access, чтобы открыть первую страницу мастера анализа таблиц, как показано на рис. 1.11. -14-  Рис. 1.11. Первая страница мастера анализа страниц дает примеры повторения, которого вы стремитесь избежать 2. Первая страница мастера анализа таблиц содержит кнопки, которые вы можете нажимать, чтобы увидеть примеры повторения. Нажимайте кнопки Показать пример. Ознакомившись с информацией, которая появится после нажатия кнопок, щелкните по кнопке Next (Далее). Следующая таблица, показанная на рис. 1.12, похожа на первую она чисто учебная. Нажмите Далее после просмотра примеров и проследуйте на страницу мастера № 3.  Рис. 1.12. Вторая страница мастера анализа таблиц показывает, что одну таблицу можно разбить на две или более таблиц -15- 3.На стр. мастера № 3 выберите CustOrder, а затем нажмите Далее, чтобы перейти на страницу мастера № 4. Вы можете предоставить мастеру возможность решить самому (или сами сделать выбор), какие поля в какие таблицы поместить. В этом упражнении пусть мастер решит сам. Выберите этот вариант и нажмите Далее, чтобы открыть страницу мастера № 5. 4.Страница мастера № 5 - диаграмма, показывающая таблицы, поля и зависимости визуально. Щелкните по полю CustName в табл.5 и перетащите его назад таблицу 2, как показано на рис. 1.13.   Рис. 1.13. Вы можете перемещать поля между таблицами на ар. мастера анализа таблиц № 5 -16- 5. Таким же образом переместите каждое поле из таблицы 4 через таблицу 6 в таблицу 2. Вы можете использовать горизонтальную и вертикальную полосы прокрутки. Перерасположите поля в правильном порядке: CustID, OrderNum, CustName, Address, City, State, Zip и Phone. Просто нажмите на любое из них, держите, не отпуская, кнопку мыши и перетащите его на нужное место, чтобы все было так, как на рис. 1.14.  Рис. 1.14. Когда поля перерасположены, можете переименовать таблицы 6.Теперь дважды щелкните по заголовку таблицы 2 и дайте ей название -Customers. Таким же образом, дайте название таблице 1 - Orders. Поместите таблицы горизонтально, перетаскивая их за строку заголовка, так, чтобы таблица Customers была слева. Оставьте зависимость «один ко многим», которую Access заранее определил для вас, и нажмите Next для перехода на страницу мастера № 6. 7.Когда страница 6 откроется, у вас будет возможность идентифицировать первичные ключи в обеих таблицах. Щелкните по CustID в таблице Customers,  Рис. 1.15. Вы можете установить первичный ключ на стр. мастера анализа таблиц № 6 -17- а затем щелкните по кнопке Установить Ключевое поле, показанной на рис. 1.15. Это должно удалить первичный ключ Созданный уникальный ID в таблице Customers. Нажмите Далее для перехода на страницу мастера № 7. 8. На стр. 1 спрашивается, нужен ли вам запрос. Нажмите «Нет, запрос создавать не нужно», а затем нажмите Готово. Закройте окно помощи после прочтения, чтобы увидеть две таблицы, показанные на рис. 1.16. Вот и все!  Рис. 1.16. Мастер анализа таблиц создал для вас две таблицы -18- Литература Виллариал Б. Программирование Access 2002 в примерах: Пер. с англ. - М.: КУДИЦ-ОБРАЗ, 2003. - 496 с. -19- |
Добавить документ в свой блог или на сайт
Похожие:
 | Урок по информатике по теме "Системы управления базами данных. Создание... Повторить понятие “База данных”, “поле базы данных”, “запись базы данных”, “субд” |  | Реферат по теме: «субд access. Основные понятия. Таблицы. Запросы.... «субд access. Основные понятия. Таблицы. Запросы. Формы. Отчёты. Создание базы данных» |
| Программа по формированию навыков безопасного поведения на дорогах... Тема: Система управления базами данных Access. Создание структуры табличной базы данных | | Тема. Создание базы данных для компьютерного психодиагностического тестирование в access Лабораторная работа №6. Обобщение данных. Создание таблицы подстановки. Подведение итогов 28 |
| Тема: Создание таблиц базы данных Microsoft Office Access. Тип урока Оборудование: компьютеры, интерактивная доска, карточка участника конкурса, тест «База данных», задание к практической работе | | Базы данных Для признания исключительного права на базы данных не требуется специальной регистрации (однако предпочтительно осуществлять государственную... |
| Тематическое планирование по теме: База данных. Прикладная среда... Тематическое планирование по теме: База данных. Прикладная среда – система управления базой данных Access | | Создание базы данных для сферы социально-культурного сервиса и туризма... |
| Программа по формированию навыков безопасного поведения на дорогах... Место урока в теме – урок проводится в ходе изучения темы “Информационные системы”, после изучения понятий базы данных, видов баз... | | Программа по формированию навыков безопасного поведения на дорогах... Место урока в теме – урок проводится в ходе изучения темы “Информационные системы”, после изучения понятий базы данных, видов баз... |
| Программа по формированию навыков безопасного поведения на дорогах... Цель работы: получить практические навыки работы с реляционными структурами данных на примере субд ms office Access. Научиться визуализировать... | | Курсовая работа Тема: «Создание базы данных ’’Поставщики’’» Базы данных обеспечивают надежное хранение информации, структурированном виде и своевременный доступ к ней. Практически любая современная... |
| Задание Использование макросов в базе данных Microsoft Access Исследовать... Определять реакцию приложения на различные события в формах и отчетах, такие как нажатие кнопок, изменения данных, открытие и закрытие... | | Понятие информационно – коммуникационных технологий – (икт) и их роль в образовательном процессе Повторить понятие “База данных”, “поле базы данных”, “запись базы данных”, “субд” |
| Базы данных, экспертные системы реферат «Реляционная модель данных... ... | | Конспект урока «Проектирование Базы Данных: построение инфологической модели предметной области» Положением об итоговой государственной аттестации выпускников Омского государственного технического университета |
