Макет базы данных – Модели баз данных | Системы управления базами данных

Модели баз данных | Системы управления базами данных

СУБД используют различные модели данных. Самые старые системы можно разделить на иерархические и сетевые базы данных — это пререляционные модели.

В иерархической модели элементы организованы в структуры, связанные между собой иерархическими или древовидными связями. Родительский элемент может иметь несколько дочерних элементов. Но у дочернего элемента может быть только один предок.

«Система управления информацией» (Information Management System) компании IMB — пример иерархической СУБД.

Иерархическая модель организует данные в форме дерева с иерархией родительских и дочерних сегментов. Такая модель подразумевает возможность существования одинаковых (преимущественно дочерних) элементов. Данные здесь хранятся в серии записей с прикреплёнными к ним полями значений. Модель собирает вместе все экземпляры определённой записи в виде «типов записей» — они эквивалентны таблицам в реляционной модели, а отдельные записи — столбцам таблицы. Для создания связей между типами записей иерархическая модель использует отношения типа «родитель-потомок» вида 1:N. Это достигается путём использования древовидной структуры — она «позаимствована» из математики, как и теория множеств, используемая в реляционной модели.

Рассмотрим в качестве примера иерархической модели данных организацию, хранящую информацию о своём работнике: имя, номер сотрудника, отдел и зарплату. Организация также может хранить информацию о его детях, их имена и даты рождения.

Данные о сотруднике и его детях формируют иерархическую структуру, где информация о сотруднике – это родительский элемент, а информация о детях — дочерний элемент. Если у сотрудника три ребёнка, то с родительским элементом будут связаны три дочерних. В иерархической базе данных отношение «родитель-потомок» — это отношение «один ко многим». То есть у дочернего элемента не может быть больше одного предка.

Иерархические БД были популярны, начиная с конца 1960-х годов, когда компания IBM представила свою СУБД «Система управления информацией. Иерархическая схема состоит из типов записей и типов «родитель-потомок»:

• Запись — это набор значений полей.
• Записи одного типа группируются в типы записей.
• Отношения «родитель-потомок» — это отношения вида 1:N между двумя типами записей.
• Схема иерархической базы данных состоит из нескольких иерархических схем.

В сетевой модели данных у родительского элемента может быть несколько потомков, а у дочернего элемента — несколько предков. Записи в такой модели связаны списками с указателями. IDMS («Интегрированная система управления данными») от компании Computer Associates international Inc. — пример сетевой СУБД.

Иерархическая модель структурирует данные в виде древа записей, где есть один родительский элемент и несколько дочерних. Сетевая модель позволяет иметь несколько предков и потомков, формирующих решётчатую структуру.

Сетевая модель позволяет более естественно моделировать отношения между элементами. И хотя эта модель широко применялась на практике, она так и не стала доминантной по двум основным причинам. Во-первых, компания IBM решила не отказываться от иерархической модели в расширениях для своих продуктов, таких как IMS и DL/I. Во-вторых, через некоторое время её сменила реляционная модель, предлагавшая более высокоуровневый, декларативный интерфейс.

Популярность сетевой модели совпала с популярностью иерархической модели. Некоторые данные намного естественнее моделировать с несколькими предками для одного дочернего элемента. Сетевая модель как раз и позволяла моделировать отношения «многие ко многим». Её стандарты были формально определены в 1971 году на конференции по языкам систем обработки данных (CODASYL).

Основной элемент сетевой модели данных — набор, который состоит из типа «запись-владелец», имени набора и типа «запись-член». Запись подчинённого уровня («запись-член») может выполнять свою роль в нескольких наборах. Соответственно, поддерживается концепция нескольких родительских элементов.

Запись старшего уровня («запись-владелец») также может быть «членом» или «владельцем» в других наборах. Модель данных — это простая сеть, связи, типы пересечения записей (в IDMS они называются junction records, то есть «перекрёстные записи). А также наборы, которые могут их объединять. Таким образом, полная сеть представлена несколькими парными наборами.

В каждом из них один тип записи является «владельцем» (от него отходит «стрелка» связи), и один или более типов записи являются «членами» (на них указывает «стрелка»). Обычно в наборе существует отношение 1:М, но разрешено и отношение 1:1. Сетевая модель данных CODASYL основана на математической теории множеств.

Известные сетевые базы данных:

• TurboIMAGE;
• IDMS;
• Встроенная RDM;
• Серверная RDM.

В реляционной модели, в отличие от иерархической или сетевой, не существует физических отношений. Вся информация хранится в виде таблиц (отношений), состоящих из рядов и столбцов. А данные двух таблиц связаны общими столбцами, а не физическими ссылками или указателями. Для манипуляций с рядами данных существуют специальные операторы.

В отличие от двух других типов СУБД, в реляционных моделях данных нет необходимости просматривать все указатели, что облегчает выполнение запросов на выборку информации по сравнению с сетевыми и иерархическими СУБД. Это одна из основных причин, почему реляционная модель оказалась более удобна. Распространённые реляционные СУБД: Oracle, Sybase, DB2, Ingres, Informix и MS-SQL Server.

«В реляционной модели, как объекты, так и их отношения представлены только таблицами, и ничем более».

РСУБД — реляционная система управления базами данных, основанная на реляционной модели Э. Ф. Кодда. Она позволяет определять структурные аспекты данных, обработки отношений и их целостности. В такой базе информационное наполнение и отношения внутри него представлены в виде таблиц — наборов записей с общими полями.

Реляционные таблицы обладают следующими свойствами:

• Все значения атомарны.
• Каждый ряд уникален.
• Порядок столбцов не важен.
• Порядок рядов не важен.
• У каждого столбца есть своё уникальное имя.

Некоторые поля могут быть определены как ключевые. Это значит, что для ускорения поиска конкретных значений будет использоваться индексация. Когда поля двух различных таблиц получают данные из одного набора, можно использовать оператор JOIN для выбора связанных записей двух таблиц, сопоставив значения полей.

Часто у полей будет одно и то же имя в обеих таблицах. Например, таблица «Заказы» может содержать пары «ID-покупателя» и «код-товара». А в таблице «Товар» могут быть пары «код-товара» и «цена». Поэтому чтобы рассчитать чек для определённого покупателя, необходимо суммировать цену всех купленных им товаров, использовав JOIN в полях «код-товара» этих двух таблиц. Такие действия можно расширить до объединения нескольких полей в нескольких таблицах.

Поскольку отношения здесь определяются только временем поиска, реляционные базы данных классифицируются как динамические системы.

Первая модель данных, иерархическая, имеет древовидную структуру («родитель-потомок»), и поддерживает только отношения типа «один к одному» или «один ко многим». Эта модель позволяет быстро получать данные, но не отличается гибкостью. Иногда роль элемента (родителя или потомка) неясна и не подходит для иерархической модели.

Вторая, сетевая модель данных, имеет более гибкую структуру, чем иерархическая, и поддерживает отношения «многие ко многим». Но быстро становится слишком сложной и неудобной для управления.

Третья модель — реляционная — более гибкая, чем иерархическая и проще для управления, чем сетевая. Реляционная модель сегодня используется чаще всего.

Объект в реляционной модели определяется как позиция информации, хранимой в базе данных. Объект может быть осязаемым или неосязаемым. Примером осязаемого объекта может быть сотрудник организации, а примером неосязаемой сущности — учётная запись покупателя. Объекты определяются атрибутами — информационным отображением свойств объекта. Эти атрибуты также известны как столбцы, а группа столбцов — как ряд. Ряд также можно определить как экземпляр объекта.

Объекты связываются отношениями, основные типы которых можно определить следующим образом:

В этом виде отношений один объект связан с другим. Например, Менеджер -> Отдел.

У каждого менеджера может быть только один отдел, и наоборот.

В моделях данных отношение одного объекта с несколькими. Например, Сотрудник -> Отдел.

Каждый сотрудник может быть только в одном отделе, но в самом отделе может быть больше одного сотрудника.

В заданный момент времени объект может быть связан с любым другим. Например, Сотрудник -> Проект.

Сотрудник может участвовать в нескольких проектах, и каждый проект может объединять несколько сотрудников.

В реляционной модели объекты и их отношения представлены двухмерным массивом или таблицей.

Каждая таблица представляет объект.

Каждая таблица состоит из рядов и столбцов.

Отношения между объектами представлены столбцами.

Каждый столбец представляет атрибут объекта.

Значения столбцов выбираются из области или набора всех возможных значений.

Столбцы, которые используются для связи объектов, называются ключевыми. Есть два типа ключей — первичные и внешние.

Первичные служат для однозначного определения объекта. Внешний ключ — это первичный ключ одного объекта, существующий как атрибут в другой таблице.

Преимущества реляционной модели данных:

1. Простота использования.
2. Гибкость.
3. Независимость данных.
4. Безопасность.
5. Простота практического применения.
6. Слияние данных.
7. Целостность данных.

Недостатки:

1. Избыточность данных.
2. Низкая производительность.

В последнее время на рынке СУБД появились продукты, представленные объектными и объектно-ориентированной моделью данных, такие как Gem Stone и Versant ОСУБД. Также производятся исследования в области многомерных и логических моделей данных.

Особенности объектно-ориентированных систем управления базами данных (ООСУБД):

• При интеграции возможностей базы данных с объектно-ориентированным языком программирования получается объектно-ориентированная СУБД.
• ООСУБД представляет данные как объекты одного или нескольких языков программирования.
• Такая система должна отвечать двум критериям: являться СУБД и должна быть объектно-ориентированной. То есть должна насколько это возможно соответствовать современным объектно-ориентированным языкам программирования. Первый критерий подразумевает: длительное хранение данных, управление вторичным хранилищем, параллельный доступ к данным, возможность восстановления, а также поддержку нерегламентированных запросов. Второй критерий подразумевает: сложные объекты, идентичность объектов, инкапсуляцию, типы или классы, механизм наследования, переопределение в сочетании с динамическим связыванием, расширяемость и вычислительную полноту.
• ООСУБД дают возможность моделирования данных в виде объектов.

А также поддержку классов объектов и наследование свойств и методов классов подклассами и их объектами.

На данный момент не существует общепринятого стандарта ООСУБД. Считается, что подобные модели данных находится на ранней стадии развития.

Примеры ООСУБД:

• D Gemstone;
• IRS;
• ORION;
• ONTOS.

Применение ООСУБД:

• В конструкторских и рассредоточенных базах данных, телекоммуникации, а также в таких научных областях, как физика высоких энергий и молекулярная биология.
• Используются в специализированных областях финансового сектора.
• Во встроенных системах, пакетном программном обеспечении и системах реального времени, чтобы у пользователей была возможность создавать объекты по своему выбору.

Данная публикация представляет собой перевод статьи «Types of Database Models | Database Management System» , подготовленной дружной командой проекта Интернет-технологии.ру

www.internet-technologies.ru

Популярные шаблоны Access — Access

База данных «Борей» В этом образце шаблона базы данных показано, как можно управлять клиентами, заказами, запасами, покупками, поставщиками, отгрузкой и сотрудниками для малых предприятий. База данных может создавать 15 различных отчетов, а также изучать и настраивать базы данных Access.	Контакты Создавайте и сохраняйте исчерпывающую базу данных партнеров и поставщиков клиентов с помощью этого популярного шаблона Access. Помимо сведений о компании, должности и контактных данных вы можете создавать все запросы, добавлять контакты из Outlook, создавать почтовые наклейки и создавать отчеты, например каталоги и телефонные книги.	Студентов Создайте и настройте полную базу данных учащихся учебного заведения и их хранители с помощью этого надежного шаблона доступа. В дополнение к поддержанию идентификатора учащегося, уровня, комнаты, особых обстоятельств и контактных данных по каждому студенту и хранителю вы можете использовать множество таких запросов, как присутствие, а также создавать все полезные отчеты в Аллергиес и Медикатионс к контактным данным.
Управление событиями Создание и обслуживание базы данных событий для управления предстоящими событиями с помощью этой базы данных Access. Мощные встроенные и настраиваемые элементы навигации и фильтрации позволяют отслеживать события по времени (например, текущие события, события по неделе и сегодняшние события), а также вводить данные в режиме реального времени с помощью электронной почты, создавать и распространять их. Указывает.	Управление задачами Создание базы данных отслеживания задач для отслеживания нескольких задач, в том числе владельцев, дат начала и выполнения, а также значений процента завершения с использованием этого популярного шаблона Access. Запросы по контактам, открытые задачи и просроченные задачи помогают следить за сведениями о задачах, их приоритетах и состоянии и назначать задачи, создавая полезные отчеты, например задачи, подЛежащие выполнению сегодня.	Отслеживание активов Создайте и настройте надежную базу данных для управления ресурсами Организации с помощью этого популярного шаблона Access. Храните актуальные сведения о ресурсах, включая собственность, условия, расположение, цену покупки и текущее значение, а также преимущества мощных функций запроса и сбора данных для создания комплексных отчетов.
Отслеживание ошибок ЗаРегистрируйте и разрешите ошибки в проекте с помощью этой базы данных Access, которая содержит видео, в которой описано, как настроить и использовать его.	Запасы Создайте и настройте полную базу данных складских транзакций для акций, сотрудников, поставщиков и транзакций вашей организации с помощью этого надежного шаблона доступа. Помимо сведений о каждом товаре, типе проводки, количестве и местоположении, можно создать множество полезных отчетов, на основе уровней складских запасов по поставщикам для перезаказа.	Отслеживание питание Используйте этот шаблон, чтобы создать собственную базу данных отслеживания питание для отслеживания того, насколько вы выработаете и выводятся на работу, включая подробную информацию о питание и рецептах.
Управление маркетингом Создание базы данных маркетинговых проектов для отслеживания конечных результатов, ролей сотрудников и поставщиков с использованием этого шаблона. Навигация по проектам, конечным результатам и сотрудникам, следить за бюджетами, владельцами, затратами и статусом и создавать отчеты с фокусом, такие как балансовый отчет и конечные результаты проекта, по назначению	Управление проектами Создание базы данных отслеживания проектов для отслеживания нескольких проектов, в том числе конечных результатов, владельцев и бюджетов, с использованием этого популярного шаблона Access. Навигация по проектам, задачам и сотрудникам — следить за затратами, приоритетами и статусом. Назначать задачи и создавать полезные отчеты, такие как задачи проекта и задачи по назначению;	Личная учетная запись Создайте базу данных проводок личной учетной записи, чтобы отследить доходы и платежи между внутренними категориями из сходить в здравоохранение и благотворительные пожертвования с помощью этого шаблона Access. Поиск и просмотр доходов и расходов по категориям и просмотру налоговых отчетов. Поле для заметок помогает запомнить полезные сведения для каждой транзакции.
Служба поддержки клиентов Создание базы данных обслуживания клиентов для управления несколькими заданиями, приоритетом, состоянием, клиентом и разрешением с помощью этого шаблона Access. Перемещаться по открытым делам с использованием нескольких условий, создавать статьи базы знаний и управлять ими, а также управлять сведениями о клиентах, создавая полезные отчеты, такие как открытые дела, с помощью назначенных и просроченных обращений.	Диспетчер личных контактов Создание и обслуживание базы данных бизнес-контактов и журнала звонков с помощью простого, но эффективного шаблона доступа. Помимо сведений о компании, должности и контактных данных вы можете просматривать контакты, звонки по контактам или темам, а также добавлять контакты из Outlook.	Средство отслеживания звонков Назначение и отслеживание состояния звонков клиентов с помощью этого шаблона динамического доступа. Навигация по клиентам, сотрудникам и звонкам, а также отслеживание по приоритету, состоянию и назначению. Кроме того, вы можете создавать полезные отчеты в режиме реального времени, например открыть звонки по назначениям, чтобы получить дополнительное ребро, необходимое при занятости.
Домашние запасы Создавайте и управляйте базами данных домашнего учета для хранения и управления важными данными с помощью этого шаблона Access. Поиск по имени элемента, категории или расположению с сохранением важных сведений для страховой цели, таких как условие, Дата получения и стоимость. Вложите фотографии элементов в каждую запись, чтобы обеспечить их компенсацию в случае потери или повреждения.	Время и выставление счетов Управляйте клиентскими случаями и проектами своей организации, включая выставление счетов, счета и балансовые листы с использованием этого надежного времени проекта и шаблона доступа к оплате. Поля для Owner, ворккоде и Status помогают отслеживать ход выполнения, затраченное время и затраты, когда вы создаете мгновенные отчеты по всем отсчетам от выставления счетов по Ворккоде на время сотрудника.	Главная книга счетов

support.office.com

Модель базы данных — Википедия

Материал из Википедии — свободной энциклопедии

Модель базы данных — то же, что и схема базы данных, то есть описания содержания, структуры и ограничений целостности, используемые для создания и поддержки базы данных^[1].

В литературе, статьях и в обиходной речи иногда встречается путаница термина «модель базы данных» и «модель данных». Такое использование является неверным, на что указывают многие авторитетные специалисты, в том числе К. Дж. Дейт, М. Р. Когаловский, С. Д. Кузнецов. Модель данных есть теория, или инструмент моделирования, в то время как модель базы данных (схема базы данных) есть результат моделирования. По выражению К. Дейта соотношение между этими понятиями аналогично соотношению между языком программирования и конкретной программой на этом языке^[2].

М. Р. Когаловский поясняет эволюцию смысла термина следующим образом. Первоначально понятие модели данных употреблялось как синоним структуры данных в конкретной базе данных. В процессе развития теории систем баз данных термин «модель данных» приобрел новое содержание. Возникла потребность в термине, который обозначал бы инструмент, а не результат моделирования, и воплощал бы, таким образом, множество всевозможных баз данных некоторого класса. Во второй половине 1970-х годов во многих публикациях, посвященных указанным проблемам, для этих целей стал использоваться все тот же термин «модель данных»^[3].

ru.wikipedia.org

8. Модели баз данных

Различают три основные модели базы данных — это иерархическая, сетевая и реляционная. Эти модели отличаются между собой по способу установления связей между данными.

8.1. Иерархическая модель базы данных

Иерархические модели баз данных исторически возникли одними из первых. Информация в иерархической базе организована по принципу древовидной структуры, в виде отношений «предок-потомок«. Каждая запись может иметь не более одной родительской записи и несколько подчиненных. Связи записей реализуются в виде физических указателей с одной записи на другую. Основной недостаток иерархической структуры базы данных — невозможность реализовать отношения «многие-ко-многим«, а также ситуации, когда запись имеет несколько предков.

Иерархические базы данных. Иерархические базы данных графически могут быть представлены как перевернутое дерево, состоящее из объектов различных уровней. Верхний уровень (корень дерева) занимает один объект, второй — объекты второго уровня и так далее.

Между объектами существуют связи, каждый объект может включать в себя несколько объектов более низкого уровня. Такие объекты находятся в отношении предка (объект, более близкий к корню) к потомку (объект более низкого уровня), при этомобъект-предок может не иметь потомков или иметь их несколько, тогда как объект—потомок обязательно имеет только одного предка. Объекты, имеющие общего предка, называются близнецами.

Рис. 6. Иерархическая база данных

Организация данных в СУБД иерархического типа определяется в терминах: элемент, агрегат, запись (группа), групповоеотношение, база данных.

Атрибут(элемент данных)	— наименьшая единица структуры данных. Обычно каждому элементу при описании базы данных присваивается уникальное имя. По этому имени к нему обращаются при обработке. Элемент данных также часто называют полем.
Запись	— именованная совокупность атрибутов. Использование записей позволяет за одно обращение к базе получить некоторую логически связанную совокупность данных. Именно записи изменяются, добавляются и удаляются. Тип записи определяется составом ее атрибутов. Экземпляр записи — конкретная запись с конкретным значением элементов.
Групповое отношение	— иерархическое отношение между записями двух типов. Родительская запись (владелец группового отношения) называется исходной записью, а дочерние записи (члены группового отношения) — подчиненными. Иерархическая база данных может хранить только такие древовидные структуры.

Пример. Рассмотрим следующую модель данных предприятия (см. рис. 7): предприятие состоит из отделов, в которых работают сотрудники. В каждом отделе может работать несколько сотрудников, но сотрудник не может работать более чем в одном отделе. Поэтому, для информационной системы управления персоналом необходимо создать групповое отношение, состоящее из родительской записи ОТДЕЛ (НАИМЕНОВАНИЕ_ОТДЕЛА, ЧИСЛО_РАБОТНИКОВ) и дочерней записи СОТРУДНИК (ФАМИЛИЯ, ДОЛЖНОСТЬ, ОКЛАД). Это отношение показано на рис. 7 (а) (Для простоты полагается, что имеются только две дочерние записи). Для автоматизации учета контрактов с заказчиками необходимо создание еще одной иерархической структуры: заказчик — контракты с ним — сотрудники, задействованные в работе над контрактом. Это дерево будет включать записи ЗАКАЗЧИК (НАИМЕНОВАНИЕ_ЗАКАЗЧИКА, АДРЕС), КОНТРАКТ(НОМЕР, ДАТА,СУММА), ИСПОЛНИТЕЛЬ (ФАМИЛИЯ, ДОЛЖНОСТЬ, НАИМЕНОВАНИЕ_ОТДЕЛА) ( рис. 7b). Рис. 7. Пример иерархической БД

Из этого примера видны недостатки иерархических БД:

Частично дублируется информация между записями СОТРУДНИК и ИСПОЛНИТЕЛЬ (такие записи называют парными), причем виерархической модели данных не предусмотрена поддержка соответствия между парными записями.

Иерархическая модель реализует отношение между исходной и дочерней записью по схеме 1:N, то есть одной родительской записи может соответствовать любое число дочерних.

Допустим теперь, что исполнитель может принимать участие более чем в одном контракте (т.е. возникает связь типа M:N). В этом случае в базу данных необходимо ввести еще одно групповое отношение, в котором ИСПОЛНИТЕЛЬ будет являться исходной записью, а КОНТРАКТ — дочерней ( рис. 7 c). Таким образом, мы опять вынуждены дублировать информацию.

Иерархическая структура предполагаета неравноправие между данными — одни жестко подчинены другим. Подобные структуры, безусловно, четко удовлетворяют требованиям многих, но далеко не всех реальных задач.

studfile.net

Шаблоны баз данных

При первом запуске программы MS Access открывается окно, в котором отображается новый компонент интерфейса пользователя Access 2010 – представление Backstage.

Представлением Backstage является место, в котором можно выполнять управление файлами.

При открытии программы Access вместе с командами Создать базу данных, Открыть, выполнить установку Параметров и списком последних баз данных, которые были использованы, предоставляется возможность выбора многочисленных шаблонов для создания разнообразных типовых баз данных (рисунок 1).

Шаблоны БД

Определение 1

Шаблоном MS Access является файл, который при открытии представляет полнофункциональное приложение базы данных.

При открытии базы данных на вкладке Файл отображается представление Backstage, которое содержит команды, применимые ко всей базе данных, но при этом естественно шаблоны баз данных не отображаются.

После выполнения закрытия базы данных в окне представления Backstage библиотека готовых шаблонов для приложений баз данных восстанавливается. Шаблоны типовых баз данных содержат все необходимые отчеты, запросы, формы и таблицы для предметных областей разнообразных сфер личной и деловой жизни. Подобные стандартные приложения могут быть использованы без выполнения настройки и модификации, или же взяты в виде основы и адаптированы соответственно характеру информации, которую необходимо сохранить и обработать.

После выбора необходимого шаблона достаточно определить место, в котором нужно сохранить базу данных, которая создается, и нажать кнопку Создать. После этого база данных, которая соответствует выбранному шаблону, создается и открывается автоматически, пользователю достаточно лишь выполнить введение данных.

Особенности шаблонов БД

Типовые базы данных позволяют начинающему пользователю изучить основные принципы построения базы данных и пользовательского приложения и развить практические навыки по работе в среде MS Access. При использовании типовой базой пользователю предоставляется возможность научится выполнять просмотр и изменение данных с помощью форм, выполнять запросы для получения информации из связанных таблиц, подготавливать отчеты.

Возможна загрузка новых шаблонов приложений с сайта Microsoft Office.com. В разделе шаблонов Office на выбор предлагается множество самых различных шаблонов для сложных и простых задач, использование которых возможно для собственного применения или использования в коммерческих целях.

Просмотр шаблонов из Интернета выполняется так же легко, как в случае размещения их на локальном компьютере. Шаблоны, которые имеются, для удобства обзора расположены по логическим категориям. Если выбрать шаблон для просмотра, отобразится приблизительная длительность его загрузки, размер, и, при необходимости, дополнительные системные требования. Достаточно одного щелчка, чтобы загрузить и открыть шаблон.

Шаблоны приложений MS Access 2010 предоставляют возможность ускорить создание приложений и приступить к работе с ними, особенно это важно в том случае, когда у пользователя нет навыков проектирования баз данных и знания языков программирования.

Замечание 1

Обратим внимание, что при использовании типовой базы данных не стоит рассчитывать на то, что она полностью сможет удовлетворить желания пользователя. База данных, которая создана по шаблону, может быть изменена и расширена, но такая работа потребует от пользователя практически тех же усилий и знаний, что и при создании новой базы данных.

Среди шаблонов баз данных MS Access наиболее часто используемым для обучения работы с базами данных является Борей.

spravochnick.ru

Создание макетов таблиц, образующих базу данных.

Практическое создание базы данных.

1. Запустить Microsoft Access и щелкнуть справа по строчке «Новая база данных».

2. В качестве имени файла набрать свою фамилию, а затем щелкнуть на кнопке «Создать».

 

 

Создание макетов таблиц, образующих базу данных.

Проектируемая база данных должна содержать три следующие таблицы.

Заказы
Номер заказа	Код клиента	Код продукта	Количество	Дата

Первичный ключ у этой таблицы – «номер заказа».

 

Клиенты
Код клиента	Наименование	Адрес

 

Первичный ключ у таблицы клиенты — поле «код клиента».

 

Продукты
Код продукта	Название	Цена

 

Первичный ключ – «код продукта».

 

При разработке базы данных сначала создаются макеты таблиц, а затем таблицы наполняются данными. Создадим сначала макет таблицы «Клиенты».

1. В окне базы данных щелкнуть на закладке «Таблицы» и щелкнуть по кнопке «Создать».

2. Выделить строчку «Конструктор» и нажать ОК.

3. В первой строке столбца «Имя поля» набрать имя «Код клиента» (без кавычек конечно) и нажать на клавишу «Таб».

4. В столбце «Тип данных» выбрать из списка «Числовой», а внизу в строке «Размер поля» должно стоять «Длинное целое». Если это не так, надо щелкнуть мышкой в этой строке и выбрать из списка «Длинное целое». Затем надо удалить нолик из строки «Значение по умолчанию».

3. Щелкнуть в строке «Обязательное поле» и выбрать из списка «Да».

4. Щелкнуть в строке «Индексированное поле» и выбрать из списка «Да(Совпадения не допускаются)». На этом создание поля «Код клиента» можно считать законченным.

Аналогично создаётся следующее поле «Наименование», только тип данных будет «Текстовый», а остальные свойства надо установить по смыслу.

Ну и наконец, третье поле «Адрес» тоже имеет тип данных «Текстовый», только размер поля нужно установить равным 80 символам.

 

С полями покончили, теперь надо указать какие поля входят в первичный ключ. Для этого их надо выделить. Как? Нажать и удерживать нажатой клавишу Ctrl, подвести указатель мыши слева от имени выделяемого поля и когда он примет вид утолщенной жирной стрелки направленной вправо щелкнуть левой кнопкой. Так вот и прощелкать по тем полям, которые входят в первичный ключ.

Так как в создаваемой таблице первичный ключ состоит всего из одного поля «Код клиента», то нажимать Ctrl нет необходимости.

После того как поля первичного ключа выделены, необходимо в панели инструментов щелкнуть по кнопке с изображением ключа. После этого слева от имен полей, входящих в первичный ключ, должно появиться изображение ключа.

Ну, теперь осталось присвоить таблице имя. Для этого нажать в панели инструментов на кнопку «Сохранить», ввести имя таблицы «Клиенты» и на ОК. После этого закрыть окно с макетом таблицы (Как? А крестик справа вверху окна зачем?).

 

После создания макета таблицы «Клиенты» аналогичным образом создаются и макеты двух других таблиц.

В таблице «Продукты» поле «Цена» имеет тип «Числовой», а размер поля устанавливается «одинарное с плавающей точкой».

В таблице «Заказы» поле «Количество» имеет размер «одинарное с плавающей точкой», а поле «Дата» имеет тип «Дата/время» и размер поля «Краткий формат даты».

 

Установка связей между таблицами.

Проектируемая база данных содержит три таблицы, некоторые из которых являются главными, а некоторые нет. Прежде чем заполнять таблицы данными, необходимо выяснить какие из них главнее других, а для этого надо сначала разобраться со связями таблиц.

Заказы
Номер заказа	Код клиента	Код продукта	Количество	Дата

 

Клиенты
Код клиента	Наименование	Адрес

 

Продукты
Код продукта	Название	Цена

 

 

Две таблицы называются связанными, если у них имеются одноименные поля. Одноименные поля – это такие поля, которые содержат совершенно одни и те же данные. Так таблицы «Заказы» и «Клиенты» связаны друг с другом одноименным полем «Код клиента».

Для двух связанных таблиц существует понятие главной и подчиненной таблицы. ГЛАВНОЙ из двух связанных таблиц является та, которую можно заполнять новыми данными независимо от другой. Например, из таблиц «Заказы» и «Клиенты» главной является таблица «Клиенты».

 

Чтобы установить связи необходимо сделать следующее.

1. С помощью меню «Сервис/Схема данных» открыть окно, в котором выделить все взаимосвязанные таблицы (клавишу Ctrl надо держать нажатой) и нажать на кнопку «Добавить», а потом на кнопку «Закрыть».

2. Должно появиться окно с изображением таблиц. Если между таблицами есть линии, соединяющие одноименные поля, значит программа автоматически установила связи. Если этих линий нет, надо установить связи вручную. Сначала мышкой перетащить таблицы в новые места, для того, чтобы появившиеся линии не пересекали таблиц (в нашем случае надо расположить таблицы так, чтобы таблица «Заказы» была между двумя другими таблицами).

3. Подвести указатель мыши к одноименному полю в главной таблице, нажать левую кнопку и, не отпуская ее, перетащить поле к такому же полю подчиненной таблицы, после чего отпустить левую кнопку. В появившемся окне поставить галочку у пункта «Обеспечение целостности данных» и нажать на кнопку «Создать».

4. После установки всех необходимых связей надо закрыть окно «Схема данных», подтвердив сохранение схемы.

 

Следующий этап создания базы данных – внесение данных в таблицу. Сначала данные вносятся во все главные таблицы, а затем в подчиненные. Поскольку главными таблицами являются таблицы «Клиенты» и «продукты», начинать нужно именно с них.

В окне базы данных выделить таблицу «Клиенты» и нажать на кнопку «Открыть».

Прежде чем вносить данные, надо изменить ширину столбцов таблицы, чтобы вносимые данные помещались целиком. Для этого подвести указатель мыши к границе раздела полей в строке с наименованиями полей и, когда указатель мышки примет вид перечеркнутой двунаправленной стрелки, нажать левую кнопку мыши и передвинуть границу.

Данные вносятся непосредственно в ячейки таблицы. Переход из одной ячейки в другую осуществляется либо нажатием клавиши «Таб», либо щелчком левой кнопкой мыши в соответствующем поле, либо с помощью клавиш управления курсором.

Таблицы заполняются построчно!!! Необходимо помнить, что нельзя перейти к заполнению данными другой записи пока в текущей записи не будут заполнены все обязательные поля!!!

После внесения всех данных таблицу закрыть и подтвердить сохранение внесенных изменений.

 

код клиента	наименование клиента	адрес
	кафе «Парус»	Зеленая, 12
	клуб «Белый попугай»	Лесная, 28
	закусочная «Сирена»	Весенняя, 46
	ресторан «Барракуда»	Голубева, 10
	бистро «Париж»	Московская, 7
	клуб «Орфей»	Волжская, 51

 

код продукта	название	цена
	конфеты «южная ночь»	32,6
	печенье «столичное»	16,4
	торт «птичье молоко»	35,2
	пастила фруктовая	24,8
	крекер соленый
	крекер детский	11,4

 

 

Читайте также:

Рекомендуемые страницы:

Поиск по сайту

poisk-ru.ru

Основы правильного проектирования баз данных в веб-разработке / Habr

Базы данных используются повсюду, включая большую часть проектов в мире веб-разработки. Всё, начиная от простейших блогов и каталогов, до серьезных социальных веб-проектов. Независимо от сложности сайта и соответствующей базы данных, каждый из них требует тщательного проектирования, чтобы работать эффективно, а также надежно.


В этой статье мы рассмотрим основы разработки хорошего плана базы данных, независимо от ее окончательного предназначения. Для всех вариантов структуры баз данных есть набор стандартных правил и лучших практик, которыми следует пользоваться. Они будут способствовать базе данных оставаться организованной и сделает ее взаимодействие с сайтом более разумным и эффективным способом.

Какой функционал требуется от базы данных

Первый метод, используемый при планировании, это обычный мозговой штурм, делая записи на бумаге или как-то еще, в зависимости от того, что требуется хранить в базе данных, и что будет требоваться сайту. Старайтесь не думать об конкретных полях, таблицах, которые будут использоваться в конкретном случае — все специфичные моменты будут рассмотрены вами позже. Ваша цель на данном этапе состоит в том, чтобы получить общую и полную картину структуры базы данных, которую потом будете уточнять и делать более подробной. Зачастую в дальнейшем может быть более трудным добавить какие-то элементы в ваш план, нежели на первоначальном этапе.

Фото: binaryape

Отстранитесь от базы данных. Попытайтесь подумать, что будет требоваться от сайта? Например, если требуется сделать сайт, объединяющий людей, вы, возможно, сразу начнете думать о данных, которые будут хранить пользователи. Забудьте, отложите это на потом. Лучше запишите, что пользователи и информация о них должна храниться в базе данных. А что еще? Что пользователи будут делать на вашем сайте? Будут ли они публиковать записи, загружать файлы, фотографии, писать друг другу сообщения? Следовательно, база данных должна хранить всю эту информацию: записи, файлы, фотографии, сообщения и т. д.
Как будут взаимодействовать пользователи с вашим сайтом? Будет ли у них необходимость в поиске, например, их любимых рецептов, иметь доступ к записям, доступным конкретному сообществу, искать продукты или смотреть список недавно просмотренных и купленных продуктов? В базе данных должна быть предусмотрена возможность хранить рецепты, «закрытые» записи, доступные определенному кругу пользователей, информацию о продуктах, а также возможность связи определенного продукта и пользователя.

Определение необходимых таблиц и полей

Следующий этап заключается в том, чтобы определить, какие именно таблицы и поля потребуются в базе данных. Это ядро разработки и самая сложная её часть. Использование правильных методов связки таблиц, определение структуры данных в каждой таблице, выявление необходимости разброса этих данных по разным таблицам, — все эти проблемы всплывают при непосредственном проектировании базы данных. Теперь вам необходимо определить список очевидно необходимых таблиц и полей, будьте как можно более конкретным. В ходе этого процесса, какие-то элементы могут быть перестроены либо реорганизованы в целях повышения эффективности и безопасности базы данных.

Используйте инструмент моделирования данных

Теперь, когда вы знаете, что сайт должен будет делать, самое время определить, какую конкретно информацию нужно будет хранить. Очень уместным здесь окажется инструмент для проектирования баз данных, особенно имеющий возможность создавать визуальные модели базы данных, например, MySQL Workbench либо DBDesigner4. Gliffy является отличным бесплатным он-лайн инструментом для создания различных блок-схем и моделей баз данных.

Есть также более известный, качественный, на мой взгляд, инструмент — Microsoft Visio (только под Windows, цена $249.99). Но не пугайтесь, есть более дешевые альтернативы, многие из которых являются open-source проектами, в том числе два, упомянутых выше.
Ознакомьтесь с общими графическими обозначениями и стандартными визуальными элементами, необходимым для создания модели базы данных, и начните предварительное планирование с помощью блок-схем и диаграмм. Это позволит избежать логических ошибок, прежде чем будет создана уже какая-нибудь конкретная база данных.

Реляционные базы данных

Большинство баз данных являются реляционными базами данных. Это означает, что таблицы в базе данных связаны между собой каким-либо образом. Например, если существует «пользователь» на сайте интертнет-магазина, то он наверняка может быть связан с определенными продуктами, на основании информации об их заказах либо указании желаемых продуктах. Для базы данных блога авторы должны быть как-то связаны с записями, которые они написали, а авторизованные пользователи должны быть связаны с оставленными ими комментариями.
С помощью определенных методов реляционных баз данных мы можем хранить огромное количество информации в организованном виде в отдельных таблицах: одна для пользователей, одна для записей, одна для комментариев, для продуктов и т.д. Теперь мы можем связать данные в разных таблицах, использую уникальные ключи.

Любая запись в каждой таблице должна иметь уникальный ключ. Это типа «номера социального страхования» или «штрих-кода» для записи. Он является уникальным для каждой записи. И никакая другая записи не может иметь такой же идентификатор в той же таблице. Наличие уникальных имен или названий продуктов в базе данных не достаточно. Гораздо более эффективным является использование уникальных первичных ключей. Даже несколько уникальных полей в базе данных не защищают ее от возможности дублирования данных, что впоследствии может негативно сказаться на работе сайта.
Для связи двух таблиц мы используем внешний ключ, который является всего лишь идентификатором, ссылающимся на уникальный ключ в другой таблице, обычно это первичный ключ. В примере ниже мы видим, что первая таблица содержит информацию о трех авторах с уникальным идентификатором (id). Во второй таблице мы связываем каждую запись о статье с автором через этот идентификатор. Теперь мы можем найти автора первой статьи, и наоборот, видеть, что Том написал две статьи, Мэри — одну, а Джейн еще ни одной.
Это простая модель отношения вида один-к-одному. Существую также модели один-ко-многим и многие-ко-многим.

Группировка и разделение данных

Что касается полей, также важно знать, когда группировать определенную часть данных, а когда нет. Хороший способ определить, какая информация должна быть в одном поле или наоборот, подумать, будет ли необходимость изменять какую-либо её часть? Например, нужно ли хранить адрес, разбив его на составляющие: 1) улица, 2) город, 3) штат, 4) почтовый код, 5) страна?
Это неотъемлемая часть функционала сайта (возможно, пользователи или администраторы захотят искать других пользователей по адресу или штату), или просто увеличение места, занимаемого базой данных на диске? Если это не столь важно, зачем тогда нагружать базу данных на изменение 5 полей, когда можно обновить всего лишь одно строковое поле. Более удобным может быть вариант получения этих данных из HTML-формы, где поля разделены, а уже перед добавлением адреса в базу данных объединять значения из соответствующих полей в одну строку.
Это только один пример, но всегда имейте представление о наиболее эффективные способы организации полей таблицы, когда объединять их, когда содержать отдельно, ради поддержания функциональности сайта.

Нормализация базы данных

Нормализация представляет набор руководящих принципов, созданных для организации более эффективного хранения информации. Мы уже упоминали о некоторых важных основных практиках, которые входят в наиболее популярные нормальные формы. Есть пять нормальных форм. Было бы полезным ознакомиться с этими нормальными формами и разрабатывать базы данных в соответствии с их требованиями.
Нормализация базы данных большая тема, но уже понимание ее основ может вам чрезвычайно помочь. Чтобы иметь общее представление о каждой нормальной форме и нормализации в целом, не забудьте взглянуть на Основы нормализации баз данных.

Заключение

Проектирование баз данных — обширная тема, но от вас не потребуется многого, чтобы изучить основы и иметь представление о правильной структуре баз данных. Может быть, наиболее важным этапом проектирования базы данных является само его начало и мозговой штурм. Это то, что позволяет любому разработчику получить всю необходимую информацию заранее и реализовывать задуманное по мере необходимости. Только имея всю необходимую информацию для проектирования, можно создать эффективную базу данных с правильно связанными таблицами.
Любая база данных должна быть эффективной и масштабируемой. Данные постоянно редактируются, добавляются, удаляются, поэтому важным будет содержать базу данных организованной таким образом, чтобы поддерживать этот постоянно изменяющийся набор данных. Убедитесь, чтобы в создаваемой базе данных удалялась только та информация, которая должна, не дублировались бы записи и можно было бы ссылаться на другие данных легко и просто.

Дополнительные ресурсы

p.s. Претензии по переводу в личку приветствуются. Спасибо всем, кто не мешал 🙂

habr.com

No related posts.