Логическое проектирование бд. Правила преобразования км в рм для связи 1:1, 1:м, м:м.
При проектировании любой базы данных всегда следует иметь в виду конечного пользователя. Логическое проектирование базы данных (также называемое построением ее логической модели) представляет собой процесс объединения данных в логически организованные группы объектов, которые можно легко поддерживать. Логическое проектирование базы данных должно приводить к уменьшению повторяющейся информации или даже полному ее устранению. В конце концов, зачем хранить одни и те же данные дважды? Кроме того, все используемые в базе данных соглашения о наименованиях также должны быть стандартными и логически обоснованными.
Преобразование ER – модели в реляционную модель.
Существует несколько правил позволяющие осуществить переход:
1. Каждый тип сущности преобразуется в таблицу. В эту табл. вносятся все атрибуты.
2. Бинарная связь типа один ко многим между сущностями разных типов, реализуется с помощью внешнего ключа между 2-мя табл.
3. Каждая связь со степенью > 2 и связь имеющая атрибуты преобразуется в табл.
4. Связь 1-1 реализуется в рамках одной табл. исключение из этого правила является ситуация, когда связанные сущности существенно не зависимы друг от друга.
5. Унарная связь 1-М между сущностями одного типа реализуются с помощью внешнего ключа определенного в той же табл. что и первичный ключ.
6. Бинарная связь типа М-М реализуется с помощью промежуточной табл.
7. Унарная связь многие ко многим реализуется с помощью промежуточных табл.
К не реализуемым относятся связь один ко многим или многие ко многим обязательно в обе стороны.
Таблицу можно создать без первичного ключа. В качестве первичного ключа может выступать любой уникальный атрибут, кот. не повторяется. Если у сущности нет
уникальных атрибутов, то рассматриваются уникальные комбинации атрибутов.
Первичный ключ не должен быть доменным (состоять из большого кол-ва атрибутов). При отсутствии подходящих атрибутов вводится суррогатный ключ, кот. не несет смысловой нагрузки и служит только для идентификации.
Технологии использования бд. Функции приложения в архитектуре Клиент-Сервер.
1.функции ввода и отображения данных
2.прикладные функции, определяющие основные алгоритмы
3.функции обработки данных внутри приложения
4.функции управления информационными ресурсами
5.служебные функции.
Архитектура многопользовательских субд. Модели 2-уровневой архитектуры клиент –Сервер. Достоинства, недостатки.
Основным назначением трехуровневой архитектуры является обеспечение независимости от данных.
Клиент-Сервер:
Систему баз данных можно рассматривать как систему, где осуществлено распределение процесса выполнения по принципу взаимодействия двух программных процессов, один из которых в этой модели называется «клиентом», а другой, обслуживающий клиента, — сервер (машина баз данных). Клиентский процесс запрашивает некоторые услуги, а серверный процесс обеспечивает их выполнение. При этом предполагается, что один серверный процесс может обслужить множество клиентских процессов.
Сервер в простейшем случае — это собственно СУБД. Клиенты — это различные приложения, которые выполняются над СУБД.
Обычно в приложении выделяются следующие группы функций: функции ввода и отображения данных (презентационная часть приложения определяется тем, что пользователь видит на своем экране, основными задачами этой части являются: формирование экранных изображений; чтение и запись в экранные формы информации; управление экраном; обработка движений мыши и нажатий клавиш клавиатуры); прикладные функции (определяют основные алгоритмы решения конкретных задач приложения, код приложения пишется с использованием раз¬личных языков программирования); функции обработки данных внутри приложения (Для обеспечения доступа к данным используются язык запросов и средства манипулирования данными стандартного языка SQL); функции управления информационными ресурсами (это СУБД, которая обеспечивает хранение и управление базами данных); служебные функции (выполняют роль связок между функциями других групп).