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

ЛИЧНЫЙ КАБИНЕТ 

 

Здравствуйте гость!

 

Логин:

Пароль:

 

Запомнить

 

 

Забыли пароль? Регистрация

Повышение уникальности

Предлагаем нашим посетителям воспользоваться бесплатным программным обеспечением «StudentHelp», которое позволит вам всего за несколько минут, выполнить повышение уникальности любого файла в формате MS Word. После такого повышения уникальности, ваша работа легко пройдете проверку в системах антиплагиат вуз, antiplagiat.ru, etxt.ru или advego.ru. Программа «StudentHelp» работает по уникальной технологии и при повышении уникальности не вставляет в текст скрытых символов, и даже если препод скопирует текст в блокнот – не увидит ни каких отличий от текста в Word файле.

Результат поиска


Наименование:


статья Интеграция языков программирования с базами данных: в чем состоит проблема?

Информация:

Тип работы: статья. Добавлен: 20.05.2012. Сдан: 2011. Страниц: 9. Уникальность по antiplagiat.ru: < 30%

Описание (план):


Интеграция  языков программирования с базами данных: в чем состоит  проблема?

Вильям Кук (William R. Cook), Али Ибрагим (Ali H. Ibrahim)  
Перевод: 
Сергей Кузнецов  
Оригинал: 
Integrating Programming Languages & Databases: What's the Problem?

Предисловие переводчика

Проблема «потери  соответствия» (impedance mismatch) между языками программирования и системами баз данных обсуждается в сообществе баз данных на протяжении всей моей профессиональной жизни. Попытки решения этой проблемы породили направления языков программирования баз данных, объектно-ориентированных и, отчасти, объектно-реляционных баз данных.
В статье Кука и  Ибрагима предлагается взгляд на проблему потери соответствия со стороны членов сообщества объектно-ориентированного программирования. Всегда интересно  увидеть проблему чужими глазами. Некоторые мысли авторов, например, по поводу оптимизации доступа к постоянно хранимым данным кажутся мне, как человеку из сообщества баз данных, достаточно неожиданными. Но именно это и интересно.
Авторы статьи не являются специалистами в области  баз данных, и поэтому иногда в статье используется не очень корректная терминология. Я не стал править авторский текст для устранения этих небольших дефектов. К статье прилагается хороший список литературы. К сожалению, не все тексты статей публично доступны в Internet, но я постарался подобрать ссылки на доступные статьи. Надеюсь, что кому-нибудь это принесет пользу.

Аннотация

Проблема интеграции баз данных и языков программирования остается открытой на протяжении почти 45 лет. В течение этого времени  достигнут большой прогресс в исследованиях специализированных языков программирования баз данных, ортогональной персистентности, объектно-ориентированных баз данных, моделей транзакций, библиотек доступа к данным, встраиваемых запросов и объектно-реляционного отображения. Хотя решения предлагаются каждый год, ни одно из них не оказалось полностью удовлетворительным. Одним из объяснений этой ситуации является то, что сама проблема не является достаточно четко определенной, и поэтому постоянно предлагаемые частные решения оцениваются на основе неполных метрик, что затрудняет направленный прогресс. В этой статье предпринимается попытка прояснить проблему, а не предложить какое-либо ее новое решение. Анализируются вопросы, возникающие на границе между языками программирования и базами данных, включая типизацию, оптимизацию и повторное использование. Разрабатываются конкретные критерии оценки решений, и эти критерии применяются к упомянутым выше решениям. Анализ показывает, что прогресс действительно достигнут, хотя открытой остается проблема одновременного соответствия всем критериям.
Обновлено 10/12/2005
  Все очень просто. Давайте  договоримся: каждый будет в своем  углу. Вы здесь, вы там, а я тут. И давайте  молчать: ни слова, ладно? Это не так уж сложно. У каждого из нас  есть свои мысли. Жан-Поль Сартр. За закрытыми дверями 
Перевод Л. Каменской.

1. Введение

Программы, использующие базы данных, являются важной частью нашей  информационной инфраструктуры. В этих системах языки программирования используются для вычислений общего назначения, а базы данных – для надежного и безопасного управления параллельным доступом к данным, поиска в больших объемах данных и обновления данных. Такие системы во все возрастающем количестве разрабатываются с использованием процедурных объектно-ориентированных языков и реляционных баз данных. Для обеспечения масштабируемости и надежности несколько серверов приложений обычно взаимодействует с совместно используемым, реплицируемым сервером баз данных.
Процедурные языки  и языки запросов баз данных основываются на разных семантике и стратегиях оптимизации. Эти различия неформально  называются «потерей соответствия» (impedance mismatch) [32]: между императивными программами и декларативными запросами; алгоритмами и структурами данных, с одной стороны, и отношениями и индексами, с другой стороны; потоками управления и транзакциями; пустыми указателями и неопределенными значениями в смысле отсутствия данных. Различаются также подходы к модульности и сокрытию информации. Поскольку базы данных и языки программирования могут выполнять много одинаковых задач, разработчикам приходится принимать архитектурные решения по поводу функциональной организации и разделения системы. Для распределенного исполнения также требуются эффективная структуризация и управление специализированными паттернами коммуникаций. В результате приложения, нуждающиеся в доступе к базам данных, трудно проектировать и разрабатывать. Языки программирования не облегчают эффективное использование баз данных, и для достижения хорошей производительности обычно требуется тщательная оптимизация, основанная на экспертных знаниях, что затрудняет сопровождение и развитие программ.
Эта статья позволяет  лучше понять суть потери соответствия, или проблемы интеграции баз данных и языков программирования. Аспекты, влияющие на пограничный слой между  языками программирования и базами данных, исследуются для создания списка критериев оценки решений. Эти критерии разбиваются на три основных категории: типизацияоптимизация и повторное использование. При выборе критериев мы полагаемся на свой опыт разработки коммерческих приложений, ориентированных на данные, и на применение теории языков программирования и баз данных. Процесс выбора критериев является, по сути, субъективным, но пригодность критериев определяется их возможностью выявления полезных различий между разными подходами к решению проблемы.
Мы применяем  свои критерии к ряду конкретных решений проблемы потери соответствия, включая объектно-ориентированные базы данных, объектно-реляционные преобразователи, API для доступа к данным, языки программирования с ортогональной персистентностью и встраиваемые языки запросов. Рассматриваются подходы, включающие модификации либо языков программирования, либо интерфейсов баз данных. Однако наши критерии позволяют оценивать аспекты и языков программирования, и баз данных, так что решение, обеспечивающее понятную программную модель, но не поддерживающее оптимизацию в стиле баз данных, не будет считаться удачным решением проблемы потери соответствия.
В ходе своих  рассуждений мы выделяем области, в  которых удалось достичь существенного  прогресса, а также те области, где  требуются дополнительные исследования. Предлагаемые критерии обеспечивают полезный базис для понимания решений, принимаемых архитекторами при выборе подхода к интеграции языков программирования и баз данных, а также ориентиры для дальнейших исследований. Мы полагаем, что основной причиной сложности проблемы потери соответствия является затруднительность соответствия всем критериям одновременно.

2. Родственные исследования

В этом разделе  анализируются статьи, посвященные  разъяснению проблем, которые встречаются  при интеграции языков и баз данных. Конкретные интеграционные решения обсуждаются в основных разделах статьи.
В 1987 г. Аткинсон и Бьюнман опубликовали статью [6], в которой анализировались ранние исследования в области интеграции языков программирования и баз данных; в своей статье они сосредотачиваются на создании четкой, единой программной модели персистентных данных, обеспечивающей каркас для дальнейших исследований. Дэвид Майер в [32] сформулировал ключевое требование для решений проблемы потери соответствия: «Какой бы ни была модель программирования баз данных, она должна допускать вынесение из программ сложных операций над большими объемами данных и их выполнение менеджером памяти, а не принуждать программистов к использованию интерфейса уровня записей». Блюм и Здоник в [12] выявили культурные и технические различия между языками программирования и базами данных, включая управление параллелизмом, триггеры, оптимизацию и масштабирование данных. Манифест систем объектно-ориентированных баз данных [4] не включал какие-либо требования к интерфейсу ООБД с языками программирования, и производительность не включалась в состав требований верхнего уровня. Десять лет спустя Кэри и Девитт предсказали кончину персистентных языков программирования и объектно-ориентированных баз данных, а также итоговый успех объектно-реляционных баз данных [14]. Они также идентифицировали в качестве одной из ключевых исследовательских проблем интеграцию баз данных и языков программирования, которую они назваликлиентской интеграцией. Аткинсон в [5] анализировал сложность экспериментальной проверки нового подхода к персистентности.
Йордан в [29] сравнивает персистентные среды для платформы Java. В [15] Йордан характеризует реализацию эталонного тестового набора OO7 как Java-программу, манипулирующую Java-объектами, расположенными в основной памяти. Затем этот тестовый набор используется в качестве стандарта для количественного и качественного сравнения. К сожалению, тестовый набор OO7 моделирует только единственного пользователя, так что не затрагивается важный аспект параллельности. Йордан также предполагает, что все данные могут поместиться в основной памяти. Наконец, тестовый набор OO7 не представляет наиболее распространенные операции в типичных транзакционных/корпоративных приложениях, поскольку фокусируется на обходе иерархических структур. OO7 создавался для тестирования той разновидности специализированных приложений, для которой разрабатывались объектно-ориентированные базы данных. Йордан приводит числовые показатели производительности, но не обобщает свой количественный анализ. В этом обзоре мы не приводим числовые показатели производительности. Вместо этого мы предполагаем, что языки программирования должны давать возможность доступа к оптимизациям базы данных, и приводим качественный анализ того, насколько эффективными они являются при обеспечении этого доступа.

3. Типизация

Сложности согласования типов между языками программирования и базами данных традиционно считаются ключевой причиной потери соответствия.
И в языках программирования, и в базах данных имеется поддержка  примитивных типов и структур данных. Хотя детали отображения разных представлений данных могут вызывать неприятные проблемы, на концептуальном уровне модели данных в языке программирования и в базе данных являются совместимыми. Это не является удивительным при имеющейся универсальности методов структуризации данных. Хотя данные и типы совместимы, имеются существенные проблемы при статической типизации запросов и составных программ.
class Employee {  class Department {
    String  name;      String name;
    float salary;       Set<Employee> employees;
    Department department;     Employee manager;
}    }
Рис. 1. Пример схемы базы данных, определяемой на основе классов
3.1 Отображение данных (T1)
Примитивные типы в языках программирования обычно не соответствуют типам в базе данных, и примитивные типы в разных базах  данных обычно различаются. Например, в SQL-92 не определяется абсолютная точность многих числовых типов. Операции также могут быть не согласованными; распространенным примером является сравнение интернациональных строк.
Методы отображения  классов в реляционные базы данных являются предметом расширенных исследований и разработок [1]. В общих словах, наиболее распространенный подход заключается в определении отображений между моделью «сущность-связь» (entity/relationship, ER-моделью) и объектно-ориентированной моделью классов. ER-модель обеспечивает логическое представление структуры реляционной базы данных. В ER-модели атрибуты представляют примитивные значения данных, такие как строки символов и целые числа. Они отображаются в члены экземпляра объекта в объектно-ориентированной модели. Связи ER-модели отображаются в ссылки между объектами. Многозначная связь является коллекцией ссылок. В ER-модели может быть также представлена подтипизация, имеющаяся в объектно-ориентированной модели. В некоторых случаях имеется несколько способов выполнения отображения, и результирующие проектные решения обычно основываются на производительности или других факторах.
Например, на рис. 1 определена простая модель служащих и отделов в виде двух Java-классов. В терминах баз данных поля department и employees представляют связь один-ко-многим между Departments и Employees.
Персистентность методов. При рассмотрении отображения между объектами и базами данных некоторые исследователи предлагают персистентно сохранять методы объекта, а не только состояние объекта [7]. Иногда предлагается разрешить даже персистентность потоков управления, элементов управления пользовательских интерфейсов и сетевых соединений [30]. Учитывая, что интеграция состояния и поведения является одной из ключевых концепций объектно-ориентированного программирования, можно утверждать, что персистентное отображение, в котором не сохраняются поведение/методы, нарушает базовые принципы объектно-ориентированного программирования. С другой стороны, разделение данных и поведения оказалось достаточно полезным при разработке и развитии приложений, требующих переработки большого объема данных. Этот вопрос остается без ответа, и в данном обзоре не предлагается какой-либо критерий для оценки полезности персистентности методов.
3.2 Интеграция null-значений (T2)
Поведение null-значений в SQL отличается от поведения null-значений в большинстве процедурных объектно-ориентированных языков. В SQL null представляет «неизвестное» значение, так что примитивные операции, такие как сложение или конъюнкция, возвращают null-значение, если хотя бы один их операнд является null-значением. Например, x == null всегда возвращает null, даже если x является null-значением. С другой стороны, в агрегатных функциях SQL, таких как sum, null-значения игнорируются. В объектно-ориентированных языках программирования обычно допускаются null-значения объектных ссылок, но для примитивных типов, таких как целые числа, null-значения невозможны. В реляционных соединениях null-значения также обрабатываются как «неизвестные» значения, но разыменование null-указателя в объектно-ориентированном языке обычно приводит к возникновению исключительной ситуации.
В некоторых  языках, таких как C++ и C#, допускается  определение пользовательских типов  данных, которые соответствуют семантике баз данных, но могут использоваться вместо встроенных типов языка программирования. Такая возможность бесшовной интеграции внешних типов поддерживается не во всех языках программирования.

4. Статическая типизация  (T*)

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

5. Стили интерфейсов

Пространство  решений интеграции языков программирования и баз данных можно охарактеризовать двумя экстремумами: ортогональная персистентность и явное выполнение запросов. В конкретных решениях, анализируемых в разд. 9, используется некоторая комбинация этих двух подходов. Ортогональная персистентность – это чистый подход к персистентности, при котором механизмы персистентности или даже существование нижележащей базы данных в значительной степени скрываются от программистов. Явное выполнение запросов – это прагматический подход, позволяющий существующим языкам явно вызывать операции баз данных.
void printInfo(String prefix) {
for (Employee e in db.allEmployees() )
    if ( e.name.startsWith(prefix) && e.salary > e.manager.salary ) {
      print( e.name );
      print( e.salary );
      print( e.department.name );
    }
}
Рис. 2. Печать информации о  служащих
5.1 Ортогональная персистентность  (S1)
Ортогональная персистентность является естественным расширением традиционного понятия времени жизни переменной, позволяя объектам или значениям продолжать существовать после завершения выполнения какой-либо одиночной программы [6]. В наиболее чистом виде персистентные значения существуют до тех пор, пока на них ссылается (транзитивно) персистентный корень, хотя исследовались и способы поддержки персистентности с использованием явных операций, таких как удаление. Персистентность ортогональна, поскольку свойство персистентности значения является независимым от каких бы то ни было других факторов, включая тип значения или обстоятельства его создания.
Программы, манипулирующие персистентными данными, выглядят подобно  обычным программам. В предположении, что db является корнем персистентности, содержащим коллекцию служащих, в примере на рис. 2 находятся все служащие, фамилии которых начинаются с заданного префикса, и зарплата которых превышает зарплату их менеджера. Затем печатаются фамилия служащего, его заработная плата и название отдела.
К числу примеров систем с ортогональной персистентностью относятся PJama [7], Thor [31] и OPJ [33]. В системах с чистой ортогональной персистентностью часто реализуется собственный менеджер хранения, а не используется существующая технология баз данных. Ортогональность полезнее представлять не как бинарное свойство, а в виде спектра. При таком представлении ортогональность является показателем уровня единообразия при работе с персистентными и не персистентными данными. Это представление является разумным также и по той причине, что некоторые операции, в частности, те, которые связаны с транзакциями, осмысленны только для персистентных данных, так что требуется некоторая степень неортогональности [11].
В большинстве  объектно-ориентированных баз данных (ООБД) реализуется некоторый уровень  ортогональной персистентности, хотя часто допускается персистентность  только тех значений, которые являются объектами [16]. ООБД редко бывают чисто ортогональными, поскольку для пересистентных данных обеспечиваются специальные операции для их запросов. Некоторый уровень ортогональности обеспечивают и средства объектно-реляционного отображения. В число примеров входят TopLink, JDO, EJB и Hibernate [20263734].
5.2 Явное выполнение  запросов (S2)
Основной альтернативой ортогональной персистемности и ее историческим предшественником является выполнение запросов, написанных на специализированном языке запросов. Основным преимуществом явного выполнения запросов является то, что программист имеет возможность непосредственного взаимодействия с сервером базы данных.
string empQuery = “SELECT e.name, e.salary, d.name as deptName”
    + “FROM (Employee e INNER JOIN Department d ON d.ID = e.department)”
    + “INNER JOIN Employee m ON m.ID = e.manager”
    + “WHERE e.name LIKE ? AND e.salary > m.salary”
 
Connection conn = DriverManager.getConnection(...);
PreparedStatement stmt = con.prepareStatement(empQuery);
stmt.setString(1, prefix + “%”);
ResultSet rs = stmt.executeQuery(empQuery);
while ( rs.next() ) {
    print( rs.getString(“name”) );
    print( rs.getDecimal(“salary”) );
    print( rs.getString(“deptName”) );
}
Рис. 3. Явное выполнение запроса с использованием JDBC
Встраиваемые  запросы. Явные запросы могут встраиваться в язык программирования или обрабатываться препроцессором [27]. К числу примеров относится SQLJ [8]. Встраиваемый SQL обеспечивает статически типизированный подход к явному выполнению запросов. Как обсуждается в разд. 7, одним из существенных недостатков встраивания является отсутствие поддержки динамических запросов. Другой проблемой является то, что изменение синтаксиса языка программирования обычно приводит к нарушению работы средств рефакторинга, интегрированных сред разработки (Integrated Development Environment, IDE) и CASE-средств.
Интерфейсы  уровня вызова. Доминирующим механизмом явного выполнения запросов являетсяинтерфейс уровня вызовов (call level interface, CLI) [28], обеспечивающий языку программирования доступ к серверу баз данных на основе стандартизованного API [2824]. Ключевой характеристикой CLI является возможность выполнения запросов и команд базы данных, представленных в виде строк или других структур данных времени выполнения [26]. На рис. 3 показано, как запрос с рис. 2 может быть выполнен с использованием JDBC [24].
В большинстве  систем с ортогональной персистентностью явные запросы не поддерживаются. В некоторых, хотя и не во всех объектно-ориентированных базах данных поддержка явных запросов имеется. В большинстве средств объектно-реляционного отображения явные запросы поддерживаются в качестве дополнения к ортогональной персистентности. Иногда явные запросы добавляются для решения проблем производительности; например, в EJB 1.0 поддержка запросов отсутствовала, а в EJB 2.0 – появилась. В других системах, таких как TopLink, JDO и Hibernate, имеются сложные языки запросов. Запросы могут представляться не только символьными строками, но и структурами данных времени выполнения. В Hibernate допускается представление запросов в виде критериальных объектов. Имена полей в этих системах по-прежнему представляются в виде строк символов.
Интерфейсам уровня вызовов свойственен ряд существенных проблем. Синтаксис и типы программ баз данных не проверяются статически, так что ошибки не выявляются до времени выполнения. Для конструирования  и повторного использования запросов во время выполнения требуются сложные и чреватые ошибками манипуляции. Результаты запросов представляются как динамически типизируемые объекты, доступ к которым производится по именам строк. В некоторых ситуациях для встраиваемых запросов возможна проверка типов. Гулд, Су и Деванбу [23] применяют статический анализ для проверки программ, использующих интерфейсы уровня вызовов. Их анализ в настоящее время не покрывает параметры запросов и типы результатов и может приводить к неверным результатам при раздельной компиляции компонентов. Основным достоинством подхода является его применимость к существующим программам.
Несмотря на наличие этих проблем, во многих проектах по разработке коммерческого программного обеспечения используются интерфейсы уровня вызова для эффективного использования оптимизаторов запросов баз данных и сокращения коммуникационных задержек с целью повышения общей производительности системы.

6. Оптимизация

Для приложений, работающих с большими объемами данных, важно оптимизировать доступ к данным. Адекватная стратегия выполнения запроса  часто может оказаться на несколько  порядков быстрее прямолинейной  стратегии [41].
В примерах этого  раздела представлены распространенные оптимизации запросов, но с точки  зрения языка программирования. Для  обеспечения более глубокого  анализа решений мы разделяем  понятияпоиска и навигации. Это приблизительно соответствует разделам WHERE и SELECT в языке SQL: поиск относится к выбору подмножества интересующих пользователя объектов, а навигация используется для обработки результатов поиска. Это различие является важным, поскольку во многих решениях одно из этих понятий поддерживается лучше другого.
6.1 Оптимизация поиска
Первой проблемой  является оптимизация поиска. В простой  программе, показанной на рис. 1, тратится время, пропорциональной числу служащих, хотя лишь для немногих из них фамилия  будет начинаться с заданного префикса. Для улучшения этого алгоритма могут применяться традиционные методы оптимизации баз данных, основанные на использовании индекса. Это может существенно сократить время выполнение, которое станет пропорциональным числу служащих с фамилиями, соответствующими первому условию.
Явные индексы (P1). Распространенным методом является изменение порядка подопераций, таких как итерирование и проверка условия. Так, оптимизатор запросов может использовать индекс для вычисления множества идентификаторов записей, удовлетворяющих условию, а затем найти соответствующие данные путем поиска этих идентификаторов во втором индексе. Этот аспект плана иллюстрируется на рис. 4, где эта оптимизация применяется к исходному Java-коду.
Проверка префикса реализуется путем поиска по индексу: метод match возвращает итератор над множеством элементов индекса, соответствующих первому условию. Затем для нахождения данных о служащих используется эффективный индекс, отображающий идентификаторы записей в значения записей. Если большинство фамилий не начинается с заданного префикса, этот метод будет гораздо эффективнее линейного поиска. Явное программирование с использованием индексов поддерживается в Exodus [13] и Ontos [40].
void printInfo(String prefix) {
    for (IndexItem l in employeeNameIndex.match(“S”)) {
      Employee e = employeeID_Index.lookup(l.ID);
      if (e.salary > managerID_Index.lookup(e.managerID).salary) {
          print( e.name );
          print( e.salary );
          Department d = departmentID_Index.lookup(e.deptID);
          print( d.name );
      }
    }
}
Рис. 4. Оптимизированная выдача на печать информации о служащих
Если такие  оптимизации должны выполняться  вручную, производительность программиста существенно понижается, поскольку  даже при незначительном изменении  исходного неоптимизированного  кода, например, при добавлении в  оператор if дополнительного условия, может потребоваться значительное переписывание оптимизированного кода.
Пересылка критериев. В большинстве баз данных обеспечивается автоматическое управление индексами, и выполняется оптимизация запросов на основе детального знания структуры, содержания и расположения данных [
и т.д.................


Перейти к полному тексту работы


Скачать работу с онлайн повышением уникальности до 90% по antiplagiat.ru, etxt.ru или advego.ru


Смотреть полный текст работы бесплатно


Смотреть похожие работы


* Примечание. Уникальность работы указана на дату публикации, текущее значение может отличаться от указанного.