Press "Enter" to skip to content

Day: October 11, 2023

Changing the Style of a Legend in R

Steven Sanderson is a legend:

Before diving into code examples, let’s understand the basics. In R, legends are essential for explaining the meaning of different elements in your plot, such as colors, lines, or shapes. Legends help your audience interpret the data effectively.

In most cases, R’s base plotting system provides you with control over the legend’s size. The key functions we’ll explore are legend() and guides(). We’ll also delve into how to modify legend size in popular plotting packages like ggplot2.

Click through for those demonstrations.

Comments closed

A Simple Chart Gone Wrong

Mike Cisneros debugs a visual:

Looking at the chart, you might think, “For such a simple chart, why am I so confused?” It’s a bar chart with one data series, a title, a subtitle, and more info at the bottom. But the real challenge isn’t the design, layout, or labeling. It’s the assumptions made before creating the chart. For example, the chart uses the acronym “ADS” without explaining it. Does everyone know it means Average Daily Sales? And does “Gap Analysis” make sense to coffee shop owners?

One additional thing that I would point out is that column charts tend to imply time series, which adds even more to the confusion, as the presentation makes it look like you’re seeing the comparison of Mellow Bean versus its competition over seven time periods. Bar charts, meanwhile, tend to imply static data, so the move to a bar chart makes sense.

Comments closed

Two Takes on First Normal Form

Joe Celko defends the honor of First Normal Form:

You do not need a complete understanding of regular expressions or ICD codes to follow this article, so don’t worry too much about it. The reason for posting the simplified regular expression was to scare you. My point was that this regular expression would be a pretty impressive CHECK constraint on this column. Shall we be honest? Despite the fact that we know the best programming practice is to detect an error as soon as possible, do you believe that the original poster wrote such a constraint for the concatenated list of ICD codes?

I’m willing to bet that any such validation is being done in an input tier by some poor lonely program, in an application language. Even more likely, it’s not being done at all.

First Normal Form (1NF) says that this concatenated string is a repeated group, and we need to replace it with a proper relational construct.

In the meantime, I’ve continued my series on database normalization and call First Normal Form overrated:

In this video, we start at the ground floor with 1st Normal Form. We’ll learn what people think it is, what it really is, and why it’s not as great as it’s cracked up to be.

I agree with Joe that his ICD-10 code example is a bad database design. The area in which I don’t agree—and for this, I’m leaning heavily on C.J. Date—is that repeating groups actually violate 1NF. My video covers this in a bit more detail and I also include a quotation from Date’s recent book on database design talking about how 1NF has nothing to do with repeating groups or atomicity, and that 1NF could even include relvars inside of relvars (an example Joe shows 1NF preventing).

Comments closed

Hybrid Failover Rights from SQL Server 2022 to Azure SQL MI

Dani Ljepava explains a new benefit:

Hybrid failover rights is a new benefit that allows you to run a license-free Azure SQL Managed Instance when used as a passive DR replica for your SQL Server 2022 licensed under Software Assurance (SA), or using Pay-as-you-go billing option.

How the Hybrid Failover Rights benefit works

The new Hybrid failover rights licensing benefit is technology agnostic. You can use any technology, such is MI link as the most advanced replication technology using Always On, or perhaps LRS, ADF, transactional replication, backup and restore, or similar to setup replication between SQL Server and Managed Instance. As long as you are using Azure SQL Managed Instance only as a passive replica for your SQL Server 2022, you are eligible to apply the new licensing benefit.

Read on for more details on how you can activate this benefit.

Comments closed

Against Transparent Data Encryption in SQL Server

Andy Yun is not a fan:

Of all of the various data protection options available to us in SQL Server, I argue that Transparent Data Encryption (aka TDE) is worthless Security Theater.

TDE encrypts your data files “at rest.” This means one cannot crack open a hex editor and just start reading your raw data. And did you know that you can use a hex editor and start reading string values right out of your MDF files? Go search on that – that’s a separate tangent you can go explore.

Read on to understand the ways in which Andy finds fault with TDE.

Comments closed

A Starting Point for Data Protection

Deborah Melkin asks some questions:

If we start expanding things beyond just the technology and functionality, we can really see where the concept of data protection becomes much larger and more complex.

I admit that I’m not really up-to-speed on the technical aspects of encryption or data protection. That doesn’t fall under a lot of the work that I do. But there’s another side to data protection that’s worth talking about. It’s about knowing your data. This is where I’ve been spending a lot of my time these days.

When I ask if you know your data, I’m asking if you can answer the following questions:

Read on for some of the types of questions you’ll want to think about.

Comments closed

An Overview of Transparent Data Encryption

Chad Callihan looks at one option for securing a SQL Server instance:

This month’s T-SQL Tuesday topic comes from Matthew McGiffen, who asks us to talk about encryption and protecting data in SQL Server. To read the full topic invite, click the T-SQL Tuesday logo to the right.

For this month’s invite, I thought I’d write about Transparent Data Encryption (TDE) and give a reminder about how it relates to tempdb.

Read on for Chad’s reminder.

Comments closed