Файл: Виды связей между таблицами в реляционных базах данных (Основные понятия БД и СУБД).pdf

Введение

Основные идеи современных информационных технологий основаны на концепции, согласно которой данные должны быть организованы в базы данных, чтобы адекватно отражать изменяющийся реальный мир и удовлетворять информационные потребности пользователей. Эти базы данных создаются и работают под управлением специальных программных систем, называемых системами управления базами данных (СУБД).

Увеличение объема и структурная сложность хранимых данных, расширение круга пользователей информационных систем привели к широкому использованию наиболее удобных и относительно простых для понимания реляционных (табличных) СУБД. Для обеспечения одновременного доступа к данным множества пользователей, зачастую расположенных достаточно далеко друг от друга и от места хранения баз данных, были созданы сетевые многопользовательские версии баз данных на основе реляционной структуры. Так или иначе, они решают специфические проблемы параллельных процессов, целостности (корректности) и безопасности данных, а также авторизации доступа.

Цели данной работы:

-дать основные понятия о базах данных, описать архитектуру СУБД, модели данных;

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

Глава 1. Основные понятия БД и СУБД.

1.1 Данные и компьютеры

Восприятие реального мира может быть соотнесено с последовательностью различных, хотя иногда и взаимосвязанных, явлений. С древних времен люди пытались описать эти явления (даже когда не могли их понять). Это описание называется данными.

Традиционно сбор данных осуществляется с использованием определенных средств коммуникации (например, с использованием естественного языка или изображений) на определенном носителе (например, камне или бумаге). Обычно данные (факты, явления, события, идеи или объекты) и их интерпретация (семантика) фиксируются вместе, поскольку естественный язык достаточно гибок, чтобы представлять и то, и другое. Примером может служить выписка «Цена билета 128». Здесь «128» - заданное, а «Цена авиабилета» - его семантика.

Часто данные и интерпретация разделены. Например, «Расписание ВС» можно представить в виде таблицы, вверху которой (отдельно от данных) дается их интерпретация. Такое разделение затрудняет работу с данными (сложно быстро получить информацию из нижней части таблицы).

Использование компьютеров для хранения и обработки данных обычно приводит к еще большему разделению данных и интерпретации. Компьютер в основном имеет дело с данными как таковыми. Большая часть интерпретирующей информации вообще не записывается явно (компьютер не «знает», является ли «21,50» ценой авиабилета или временем вылета). Почему это случилось?

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

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

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

Разработчики прикладных программ (написанных, например, на BASIC, Pascal или C) размещают нужные им данные в файлах, организуя их наиболее удобным для себя способом. При этом одни и те же данные могут иметь совершенно разную организацию в разных приложениях (разная последовательность размещения в записи, разные форматы одних и тех же полей и т. Д.). Публиковать такие данные крайне сложно: например, любое изменение структуры записи файла, сделанное одним из разработчиков, приводит к необходимости для других разработчиков изменять те программы, которые используют записи этого файла.

1.2 Архитектура СУБД

СУБД должна предоставлять доступ к данным любым пользователям, в том числе тем, кто практически не имеет и (или) не хочет знать о:

· Физическое расположение данных и их описания в памяти;

· Механизмы поиска запрашиваемых данных;

· Проблемы, возникающие из-за одновременного запроса одних и тех же данных многими пользователями (прикладными программами); · Способы обеспечения защиты данных от некорректных обновлений и (или) несанкционированного доступа;

Поддержание баз данных в актуальном состоянии и многие другие функции СУБД.

При выполнении основной из этих функций СУБД должна использовать разные описания данных. Как вы создаете эти описания?

Естественно, начинать проект базы данных следует с анализа предметной области и определения требований к ней отдельных пользователей (сотрудников организации, для которой создается база данных). Более подробно этот процесс будет рассмотрен ниже, но здесь отметим, что проектирование обычно поручается человеку (группе лиц) - администратору базы данных (DBA). Это может быть как специальный сотрудник организации, так и будущий пользователь базы данных, хорошо знакомый с машинной обработкой данных.

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

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

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

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

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

1.3 Модели данных

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

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

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

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

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

Физическая организация данных оказывает большое влияние на производительность базы данных. Разработчики СУБД стараются создать максимально производительные физические модели данных, предлагая пользователям тот или иной инструментарий для настройки модели под конкретную базу данных. Многообразие методов коррекции физических моделей современных промышленных СУБД не позволяет рассматривать их в этом разделе.

Глава 2. Инфологическая модель данных «Сущность-связь»

2.1 Основные понятия

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

Сущность - это любой различимый объект (объект, который мы можем отличить от другого), информация о котором должна храниться в базе данных. Сущностями могут быть люди, места, самолеты, полеты, вкус, цвет и т. Д. Необходимо различать такие понятия, как тип сущности и экземпляр сущности. Тип сущности относится к набору однородных индивидов, объектов, событий или идей, которые действуют как единое целое. Экземпляр сущности относится к определенной вещи в коллекции. Например, типом объекта может быть ГОРОД, а экземпляром - Москва, Киев и т. Д.

Атрибут - это именованная характеристика объекта. Его имя должно быть уникальным для определенного типа сущности, но оно может быть одинаковым для разных типов сущностей (например, ЦВЕТ может быть определен для многих сущностей: DOG, CAR, SMOKE и т. Д.). Атрибуты используются для определения того, какую информацию следует собирать об объекте. Примеры атрибутов для объекта ТРАНСПОРТ: ТИП, БРЕНД, НОМЕРНАЯ ТАБЛИЧКА, ЦВЕТ и т. Д. Здесь также существует различие между типом и экземпляром. Тип атрибута COLOR имеет много экземпляров или значений: красный, синий, банановый, ночной белый и т. Д., Но каждому экземпляру объекта присваивается только одно значение атрибута.